Monday, 26 October 2015

MOS 6530 replacements

Went working on old computers, there is always a problem with getting hold of replacement ICs. Some are easier than others, WDC are manufacturing modern versions of the 6502, 6520/21 and 6522, and there are still supplies of various types of RAM. One of the more difficult to replace is the 6530.
This is an early MOS chip used in Commodore PET disk drives. It is an RRIOT, so called because it contains, in a single chip, ROM, RAM, I/O and a Timer. So this can be used to reduce chip count. Because of the ROM part, this means it is a programmable part, and so not only do you need to find a 6530 to replace a faulty one, but it has to be one with the right ROM code in it. And just to help things, they are all marked with Commodore part 9018xx-0x part numbers.
This is the controller of a Commodore PET 8250 dual disk drive, the 6530 is the middle of the three 40 pin chips, marked 901885-04.
Inside the 8250, there is no sign of the promised reduced chip count in there. In total, there are:
  • 2 6502 CPUs
  • 4 sets of RAM - a bank of 2114s (4K), 2 x RIOT (128 bytes each) and a RRIOT 64 bytes)
  • 4 sets of ROM - 3 mask ROMs (2x4K, 1x2K), one RRIOT(1K) 
  • 4 I/O chips - a 6522, a RRIOT and two RIOTs
So quite a lot on there to go wrong. In the later Commodore disk drives (the 8250LP , 8296D and SFD-1001), it looks like they had been designed to use a 6530, but they all seem to be fitted with adapter boards. These had a 6530 from another drive, and some logic so the ROM on there wasn't enabled, and a separate ROM chip which had the right code in. This was presumably a way of using up the stock of old 6530 chips. I don't have a stock pile of old 6530 chips. But I do have 6532 RIOTs. The 6532 is very similar to the 6530 but without the ROM, so RIOT is RAM, I/O and Timer. This chip is not programmable, so more easy to find. There is one in every Atari 2600, I actually use a 2600 to test 6532's.
The 6532 is still available, and is a good place to start to replace a 6530. It has the RAM (actually, it has 128 bytes, the 6530 had only 64 bytes), the same I/O and Timer, so all it needs is the 1K ROM. This can all be fitted on a plug in board. This has been done in various ways before, such as this 6530 replacement, this my interpretation, along similar lines.
There are pins on the bottom to plug into the 6530 socket (annoyingly the pins are in a different order to the 6532), a ROM chip and a 74HCT02 NOR gate to enable to ROM chip as required. 8K is the smallest size ROM I can easily get, so  I've added jumpers to select the appropriate ROM image. I have put images for 5 of the 6530 ROM dumps from, including the one in the adapter board on the 8250LP. With those ROM images, this board will replace the following 6530s:
  • 901466-04 (6530-34) - Shugart SA390 drives in 4040, DOS 2.2
  • 901483-03 (6530-28) - Micropolis 1006 drives in 8050, DOS 2.5
  • 901885-04 (6530-47) - Micropolis 1006 drives in 8050/8250, DOS 2.7
  • 901869-01 (6530-48) - MPI 101/102 drives in 8050/8250 DOS 2.7
  • 251474-01B - Matsushita JU-570-2 drives in 8250LP, DOS 2.7
It may be suitable for other 6530's, but there is another layer of complexity. There is some additional programmable logic in the 6530 to set the addresses of the devices within the chip. All the disk drive ones are the same, so this board can be used for all of those. Any others would need to be checked to see the expected address map. 
With the ROM and a 6532 installed, and the jumpers set, it's ready to go. That all plugs into the 6530 socket and this 8250 dual disk drive is now back up and running nicely.
There doesn't seem to be any issues with clearance as the 8250 case is massive. Testing that with the 8250 diagnostics, it passes all the drive performance tests fine.
Another good test is using openCBM to write disk images, and the wonderfully literal BASIC 4 'copy an entire disk' command, COPY D0 TO D1.
There's another 8250 back in service. I've got another couple of drives, an 8050 and 8250 in for repair, so there should be more on them soon.
As usual, I've got spare PCBs left, these are available from my Tindie store.

Tuesday, 20 October 2015

PET IEEE-488 diagnostic tool

This is something I had made for myself to make testing my PET microSD boards, but several people have expressed interest, so these are now available for sale.
It is basically a passthrough board that plugs into the IEEE-488 port on the rear of the Commodore PET. The status of all of the signal lines are shown on 20 LEDs. 8 show the data lines, 8 the handshaking lines, one shows power and three are not connected.
Driver chips are used to minimise the loading on the bus signals, so this can be left in place without affecting normal operation. 5v power is connected at the side.
The diagnostic board serves multiple purposes. Firstly, it can be used to test the IEEE-488 drivers on the PET. I have a simple program which sets the signals on the port one by one, so you can watch the LEDs to check they are all coming on in series. The PET can also read back the status of these pins to test both directions.
Secondly, it can be used when testing IEEE-488 devices, as you can monitor the status of the lines. Thirdly, it serves as a port saver / extender, so saves wear on the edge connector.
Finally, in conjunction with special firmware on the PET microSD, I can test the IEEE-488 drivers on there, again by cycling through the outputs.
These will be supplied with a datasette power adapter, available now as PCBs, kit or assembled units from my Tindie store.

Price including:

Here is a quick video showing the flashing lights at play:

Saturday, 17 October 2015

BBC floppy disk transfer

I've had a request to transfer some files from .ssd disk images to real 5.25" floppy disks for use on a BBC micro. In the same way as my PET microSD gives the Commodore PET a microSD card disk drive, there are similar things for the BBC. These include John Kortink's GoMMC, and the RetroClinic DataCentre. Unfortunately, most of my BBCs are out of the way at the moment, so I was looking for a quick alternative.
Serial transfer is a good option in this case. The BBC has an RS423 serial port which is sort of RS232 compatible. About 20 years ago at University I had ended up with a laptop (an NEC V30 8088 clone) which had two floppy drives and a cracked screen. I also had a BBC micro and a television set, so I ended up writing up projects and dissertations on the BBC micro in Wordwise Plus and transferring them using a serial terminal program to the PC floppy drive to take into the University library to print out. It was mainly text, although I remember some of the electronics needing dodgy ASCII art circuit diagrams that had to be completed by hand once printed out. Ah, the days before WYSIWYG was at out fingertips.
I still have the BBC micro I used then (but that is also out of reach). I did manage to find the cable I had used though as the BBC's serial connector is the rather odd 5 pin DIN 'domino' pattern, which is not very common these days.
One one end of the cable goes a BBC micro. Here an issue 4 with an 8271 and Acorn DFS, and a 40/80 track switchable disk drive. PC users had it easy with 5.25" floppy disks, they were either 360K or 1.2MB, and you could usually tell by the label on the disk (DSDD or DSHD). Things were a lot more complicated for some of the other machines. With the BBC you had 40 or 80 track, DFS or ADFS, or some other propriety systems. Some single sided, some double sided, and some where you could access both sides as separate disks, but not as a continuous block. It can be very confusing when you pick up a random disks knowing what format it was written in.
At the PC end I am using a program called DFS Explorer, this allows the transfer of .ssd files to and from real disk over serial. In the 90's setup, I had a DOS boot disk in the laptop with a autoexec.bat (or was it config.sys?) set to redirect the console to the serial port, so I could use a terminal program on the BBC as if I was typing on the laptop (the BBC had a better keyboard), and would show the output from the laptop on the TV (since the latop screen was damaged and had been removed). Here is almost the reverse of that.
To begin the transfer process, you type a few commands onto the BBC to set the baud rate (1200 baud) and tell it to listen to the serial port and process what is received as if it came from the keyboard. It is effectively typing in the program you need at the BBC end. Very neat.
The program is transferred over and you save it to a disk on the BBC (or transfer it again next time you need it). When you run it, the BBC becomes a slave to the program running on the PC end.
I initially had some problems, due to a cheap USB to serial adapter. The BASIC program transferred fine, but the handshaking is more stringent on the data transfer and it wouldn't go. The cheap USB to serial adapters are often very implemented and don't follow the RS232 spec very well. Once I switched to a proper serial port it was fine.
At the BBC end, the data is written out to disk. It can also work in reverse, so you can create .ssd images from real floppies. Since I'd found some of my old disks with the cable, I too the opportunity to read archive those. So that's worked out quite easily, no additional hardware required, other than the cable, and no need to even open up the BBC. DFS Explorer, can be used as downloaded, or you can register for £5 to support the author, which I always like to do when I find something useful like that.
This works in a similar way to CBMXfer that I've used to transfer disk images from PC to a Commodore PET and a Commodore 64. Although in the Commodore case, the drives are intelligent, so the PC interfaces direct with the drive, rather than needing to use the computer as a slave. There is also something similar under way for the Spectrum, ZXTrans. The Spectrum is short of a serial port, so I am working on building a modern replacement for the Interface 1, to give a Spectrum a real serial port, or more likely, a USB connection with a microcontroller acting as USB-serial-Spectrum.
All labelled and ready to go. Now I had better test that Repton has transferred over properly, make sure all of the levels work correctly.....

Wednesday, 7 October 2015

Which PETs support which PET microSD

This post has been left for historic information. The PET microSD is no longer in production. The replacement SD2PET is available now, more information on the pre-order page.

Not sure which PET microSD is most appropriate for your PET?

PET microSD Horizontal
PET microSD Vertical
PET microSD Internal
  • plugs into back
  • easy to access
  • datasette power
  • easily removable
  • sticks out a bit
  • plugs into back
  • easy to access
  • internally powered
  • no external wires
  • low profile
  • internally fitted
  • fit and forget
  • internally powered
  • no external wires
  • low profile
C64 / C128
C16 / Plus4

(B) - BASIC v1.0 does not support any IEEE-488 drives, so an upgrade will be required - see below.
(P) - Alternate power connection required - let me know when ordering
(E) - The internal board would need an extension cable as capacitor C1 is in the way inside the case
(I)  - IEEE-488 adapter required - see PETmicroSD on a VIC20
 *  - Tested on CBM-II B710 and BX720 with DOS 1.25 and CPM 86. Should also work on the B128 and the 600 and 700 series CBM-II machines as long as they have datasette and IEEE-488 edge connectors

If you see the BASIC 1.0 screen when you power on


and not BASIC 2.0


 or BASIC 4.0


then you need to upgrade to make use of an IEEE-488 disk drive, such as the PET microSD. The easiest way to do this is with one of my ROM/RAM boards. This is a solderless and reversible upgrade that gives selectable BASIC 1, 2 or 4 and 8K, 16K or 32K of RAM to your 2001.

UPDATE: These are current out of stock, click here to pre-oreder a PET microSD.

PET microSD on a VIC20 - VICmicroSD

This may sound strange, but you can run a PET microSD IEEE-488 disk drive replacement on a VIC20. There is already the excellent SD2IEC SD card drive for VIC20 and Commodore 64, so why would you want to do that? One reason is speed, the IEC serial bus is quite slow in comparison to the IEEE-488 parallel bus.
Of course, the VIC20 doesn't have an IEEE-488 port, so it won't fit directly, what you need is a VIC20 IEEE-488 cartridge, something like this, or the official Commodore VIC-1112.
The PET microSD plugs into the back of the IEEE-488 cart, and gets power from the datasette port as normal.
On an unexpanded VIC20, you would get something like this. Some cartridges may require a SYS call to activate, and some may only support printers, but this Stack computer services one works nicely.
You can access files using standard BASIC 2.0 disk commands, like LOAD "$",8 etc. or LOAD "INVADERS",8 - what else did you expect me to test it with?
I've backed a kickstarter for a VIC-1112 replica, which should also work with this. The same should be true of a Commodore 64. I'm on the lookout for a C64 IEEE-488 cartridge to test it, but I do already have one PET microSD user running on an SX64.
Unless you fit an internal memory upgrade to your VIC20, this takes up the cartridge slot, so you are limited to the internal 3K. I've been looking into various options and I am considering producing a VIC20 cartridge which combines an IEEE-488 adapter, a PETmicroSD and 32K RAM all in one, the VICmicroSD?

Update: That cartridge is now in development, see The Penultimate Cartridge - Part 1.