2024-11-08 19:35 UTC
Back in the day Hewlet Packard used to make really nice test instruments. That division later became Agilent, which still makes nice instruments, but there is something special about the vintage HP stuff. The substantial part of my lab consists of vintage HP gear. I really like the look and feel of them, and they are maintainable in a way that, in my opinion, current instruments generally never will be. They also come with beautiful manuals that not only tell you how to operate the instruments but also, in great detail, how they work. Even now, several decades after production it's still possible to source or manufacture parts to maintain these instruments. In some cases HP made their own special original parts that makes service a bit difficult. One such situation is the RF power meter sensor heads.
The HP RF power meters were very good performers when they came out. They consisted of the meter itself that resembled the usual HP series of instruments, but they also relied on interchangeable sensor heads. That made it possible to use the same meter with different sensor heads with different specifications and for different purposes. All well and good. The big problem here is that the sensor heads are easy to damage by running them out of specifications (like over power or input DC). What makes this even worse is that all of the HP sensor heads are made with HP special parts that are nowadays unobtainium. This has led to an abundance of cheap HP RF power meters on the market but very few matching sensor heads, and without a sensor head the meter is unusable.
I have attempted to re-create a sensor head that can be used with the HP 435A, 436A and 438A series meters.
2023-08-20 18:36 UTC
Even though the MC-10 was marketed as a low-end machine, shipping it with only 4k of RAM is extremely limiting even back when it was released. It soon became very clear to me that more RAM was going to be needed in order to do anything useful. There was an official 16k RAM expansion unit that plugged in to the expansion port. I think that was the only official expansion ever released and it was quite common among MC-10 owners. The expansion port of the MC-10 is a little different to, say the Commodore 64, where the expansion port had a dedicated place in the memory address space. In the MC-10 the expansion port has access to every address in the machine and with a single input pin an external device can disable the internal address decoding entirely and place itself anywhere in the address space. Quite flexible actually but it does require relatively complex expansion cartridges. You can not simply create a game/progam cartridge with a single ROM for example.
The expansion port comes with a drawback though. Even if it can insert devices and memory anywhere in the address space, it can not be used to expand the memory accessible by the 6847 VDP since the VDP and internal RAM is hooked up to an internal bus that is isolated from the expansion port.
Since the 6847 VDP can address up to 8k of video memory it would be nice to expand the internal 4k RAM on that internal bus to 8k so that the full potential of the 6847 could be utilized. There was actually an article published in 1987 that explained such a modification. It involved piggybacking two more 2k SRAM chips on top of the existing ones and add some additional decoding. Today I would not recommend following that article. Not only does the article contain a few critical errors but it's just an unnecessarily complicated mod that adds four more chips, and piggybacking the RAM chips makes the RF shield not fit any more. I have another approach that involves just swapping the two onboard 2k RAM chips with a single 8k RAM chip. Actually the end result is reducing the total chip count by one.
Theory
The MC-10 address decoding is a bit odd but relatively simple. The address space is divided into four 16k areas, each with it's own select lines for read, and write where applicable. These select lines are generated from address lines A14 ad A15 by U4 74LS155. The second set of select lines ($4000-$7FFF) are used for the two internal RAM chips. Since they are smaller than the 16k area they are assigned, the memory will show up repeated four times within this area. This confuses the Basic so that it detects all 16k as available memory. In order to fix this RadioShack bodged on an extra 71LS32 that gates the write signal to the RAM with address line A12 which effectively block writes to the first and last mirror of the 4k RAM in the 16k area. This makes Basic happy and correctly detects the first 4k as available memory. To make the 6847 VDP able to access all the 8k of new RAM we have to make use of its unconnected DA12 pin. The original design uses two buffers to isolate the CPU A0-A11 from the VDP DA0-DA11 address lines. The two 74LS367 buffers have no available gates to accommodate A12/DA12 and I did not want to add another big chip just for that so took a shortcut. The same way I did when designing my MC3 video card, I used a single resistor to multiplex the two address lines together. This works since the access to RAM is multiplexed, the CPU and VDP never tries to access the RAM at the same time, and the VDP is nice and tri-states the DA0-DA12 lines when not accessing the bus. Hooking the VDP DA12 pin up to the RAM directly and the CPU A12 pin via a resistor makes up a crude multiplexer where the VDP always "wins" when it has access to the bus and backs off (tri-states) when the "weak" CPU has access to the bus.Putting it all together
My idea is to remove the two internal 2k 4016 RAM chips and replace them with a single 8k 6264 RAM chip. Luck have it that the bigger 6264 is in large part pin compatible with the smaller 4016, even though the 4016 is a DIP24 and the 6264 is a DIP28. Only a few pins need to be bent out and re-arranged to make this work. This is the schematic of the modification. The 6264 will be soldered in place of one of the two 4016 chips (I used U10) . The legs 1, 2, 20, 23, 26, 27, and 28 of the 6264 bent out to the side, parallel to the board and away from the 4016 footprint. With the legs bent out the 6264 will fit into the board instead of the 4016. Then it's a matter of running a few wires around to hook up the remaining pins. Use the schematic and photos below for reference. Note that pin 1 of the 6264 is not used and should be left unconnected. The top 74LS32 gate in the schematic illustrates the bodge wire from U12 that needs to be moved from address line A12 to A13. The signals are easiest to reach using the vias as in the picture. There is no need to cut the existing A12 wire, just move it to the other via, so this mod is 100% reversible. For reference this is what the board looks like before the modification. The two 4016 RAM chips down to the right. Both will have to be removed. As always some care must be taken while desoldering and don't rush it. (As usual if you are not confident removing components like these please please please stop here.) This is the completed modification. The 6264 soldered onto the board without socket. This is a personal preference. It's not possible to use a socket and still be able reattach the RF shield. With this modification the Basic now has 7238 Bytes free and the VDP can access the whole 8k address space!2023-08-12 10:23 UTC
Shortly after I started my MC3 computer project I became aware of another computer from back in the day that was eerily similar in name and CPU choice. The TRS-80 MC-10 by RadioShack. From what I understand it was marketed as a low cost alternative to the bigger TRS-80 Color Computer but it did not sell very well. Here in Sweden it is very rare.
Basic specs
- Processor: MC6803 0.89 MHz (derived from the 3.579545 MHz NTSC color crystal) - Video generator: MC6847 (only RF output) - Sound output: Single bit software flip-flop - RAM: 4kB - ROM: 8kB - Storage: Cassette I/O - Expansion: Bit banged RS232 and an expansion port with access to system bus - Keyboard: 48-keys "Chiclet" that is actually not that bad My MC-10 is originally from Canada so it's an NTSC version. I've heard rumors of a PAL version but never seen one. First I tried hooking it up to my modern LCD TV but it did not work very well. The MC-10 can be set to either CH3 och CH4. Not only was the image practically unusable but CH3 did not work at all and setting it to CH4 made it sort of work if I the TV was set to CH3. The RF-modulator was clearly out of tune. This is the best image I managed to get out of my Samsung TV. Not good enough. Let's pop the hood and see what can be done! Armed with the service manual and schematic I went in. RadioShack sure tried to meet regulations with the MC-10. That shield is thick and needed a lot of heat to desolder. There is a shield on the back of the PCB as well held on by small clamps. That bodgy looking 74LS32 is actually part of the official schematic. It even has a label. It’s a fix for making the code in ROM detect the correct amount of RAM (more on this later). Let’s get that RF modulator out of there and have a closer look. No surprises on the PCB under the RF-modulator. The machine gets its main clock from the RF-modulator though so it will not work without it and the chip inside (MC1372) is actually the NTSC color encoder so the RF-modulator is an important part of the machine. A quick look on the spectrum analyzer made it clear why I could not get my TV to lock on the MC-10 signal. Here the modulator is set to CH3 (61.25MHz) but the actual carrier at 67.60Mhz is closer to CH4 (67.65MHz). The audio sub carrier side bands are clearly visible though. The MC-10 RF modulator 4.5MHz audio sub carrier is there and looks to be reasonably within specs. The HP 5316A and the HP 5342A are both on the same frequency reference and displays a little differently. Most likely due to the different load they put on the oscillator. The color crystal oscillator should be 3.579545MHz and is easier to measure reliably. Needs a little tweaking but is not the reason the MC-10 RF modulator carrier is off frequency. I decided not to dive deeper into this and instead focus on how to get a composite video signal out of this machine. Even though the MC1372 is designed to generate an RF signal, there is a paragraph in the datasheet about striping the RF oscillator from the circuit and having it generate composite video. I pulled the crystal and the MC1372 from the original modulator and put them on a breadboard roughly the size of the original modulator. Followed the examples straight from the MC6847 and MC1372 datasheets and got something that sure looks like a composite video signal! Moved on by adding the final two transistor output stage as described in the datasheet as well as two trimmers to set the working point of the amplifier. After some quick adjustment I was greeted with a very nice and colorful image. The output is a 3.5mm stereo jack placed in the same spot as the original RCA RF output on the modulator. This way I have both video and audio output without any modification to the case. Added an attenuator and low-pass filter for the single flippy bit audio and routed it to the jack as well. Now I could finally use the TRS-80 MC-10!Poking around
Now when I could actually look at the video output without imminent headache I started looking around using the built-in basic and the original manual. Turns out that the keyboard is actually not that bad for something like this. The thing that takes some getting used to is that there is no backspace key. To correct your typing errors you either have to press CTRL+A which will act at backspace, or CTRL+Q which will delete the entire line. There is also only one SHIFT key, to the right, and only one CONTROL key, to the left. This takes some getting used to but after a while the typing experience is actually quite good. On power on you are greeted with the basic startup screen.MICROCOLOR BASIC 1.0
COPYRIGHT 1982 MICROSOFT
That is very similar as the original 6803 Microsoft basic.MICROSOFT BASIC VER. 1.0
COPYRIGHT 1982 MICROSOFT
Comparing the disassembled MC-10 ROM with the Microsoft 6803 basic source reveals that, indeed, it is the Microsoft basic with a few added custom tokens like SOUND for making noise and SET, RESET and POINT for modifying video memory etc. In general the basic is a very run of the mill Microsoft basic which is a good thing.
Memory map
Digging further into the address decoding reveals some of the, lets call them cost saving, choices made by RadioShack. The 4k of RAM is located at all the way up at $4000-$4FFF and the incomplete address decoding makes the RAM also appear at $6000-$6FFF. The schematic explains a bit of this. The 64k address space is divided into four 16k chunks by the U4 74LS155 decoder. The first 16k chunk is unconnected making the only thing existing there is the internal CPU registers and devices. The second 16k chunk is the RAM of which only 4k is used. That's the reason for the RAM showing up at two locations, and also the reason for the bodged in U20 74LS32 which is used to disable write to RAM in the second 4k area just beyond end of real RAM. I suspect this is to make the Basic detect the correct amount of RAM on startup. The Basic memory size detection routine is quite crude and will continue counting mirrored RAM as new RAM as long as it is writable. Here RadioShack simply opted for a hardware patch instead of altering the ROM. The third 16k chunk is decoded into two single byte devices, one latch on write (U8) which controls the five bit VDP config register and one bit sound output, and one buffer on read (U14) which scans the keyboard. The last 16k area is used for the ROM. Here RadioShack made it possible to use both 8k and 16k ROMs but only 8k was ever used as far as I know. This means, just like the RAM, the ROM is mirrored on this area. One thing to watch out for here is that the ROM is referenced to using the lower half of the 16k area but the CPU vectors are at the top of the 16k area which relies on the ROM being mirrored. To sum it up the memory map looks like this: $0000-$001F --- 6803 internal registers $0020-$007F --- UNUSED $0080-$00FF --- 6803 internal RAM $0100-$3FFF --- UNUSED $4000-$4FFF --- 4kB RAM $5000-$5FFF --- mirror of 4kB RAM (read only) $6000-$6FFF --- mirror of 4kB RAM (writable) $7000-$7FFF --- mirror of 4kB RAM (read only) $8000-$BFFF --- Minimally decoded single byte I/O slot for keyboard, VDG control and sound out $C000-$FFFF --- 16kB ROM but only 8kB used and mirrored twice I will continue exploring the MC-10. One of the first things I will start working on is some form of memory expansion. 4k is simply too little to make use of all the things this machine is capable of.2022-08-28 16:43 UTC
This is a quick update to my MCFS file system to version 2.0.3 than contains stability updates to the compact flash driver as well as changes to the 'ls' and 'dir' command to now show file sizes in decimal form instead of hexadecimal.
Thank you Steve for the debugging and feedback!
Source code for MCFS 2.0.3
The source code structure is the same as for 2.0.2 and divided into four files. mcfs2.asm - main code mcfs2_rtc.asm - driver for the real-time clock mcfs2_storage.asm - driver for flash card storage mcfs2_ram.asm - variables in RAM format.asm - flash card format routine (use with caution) Make sure you read the documentation in the original article --> HERECompiling
The source files need to be combined in order to compile MCFS2. Either the assembler have the ability to read all files sequentially or they can simply be concatenated before compiling. Example 1 - all files at once# as1h mcfs2.asm mcfs2_rtc.asm mcfs2_storage.asm mcfs2_ram.asm
# as1h format.asm mcfs2_storage.asm
Example 2 - concatenation
# cat mcfs2.asm mcfs2_rtc.asm mcfs2_storage.asm mcfs2_ram.asm > combined_mcfs2.asm
# as1h combined_mcfs2.asm
# cat format.asm mcfs2_storage.asm > combined_format.asm
# as1h combined_format.asm
Care must be taken to read the files in the right order. As a reference I have included my resulting S19-files.
mcfs2.s19 format.s19
2022-08-07 17:23 UTC
After completing and testing the QSD/QSE module and the BPF module, I knew the basic concept of the transceiver was living up to my expectations (see part 4 and part 5 for more information) and now I had to take a step back to figure out how to bring this all together into a self contained radio.
My main mode of operation is SSB and I think I share that with many others. Having SSB makes it possible to also receive AM and CW which probably covers most, if not all, of my needs. CW TX is trivial to add later since it's just a carrier.
The QSD/QSE module works with I/Q signals on the AF/LF side and while I/Q signals can represent more ore less any traffic mode (AM, FM, SSB etc) it requires quite a lot of processing to be useful. In order to make this transceiver operate on SSB I need to phase shift the I and Q signals precisely 90 degrees from each other over the entire modulation range, say 300Hz-3000Hz. Nowadays this is normally done in software but I really want to try doing this the analog way using all-pass phase shift networks and see if I can make it good enough for general use.
[show older articles]