The preset tuning is unrelated to the main dial tuning position. You just need to set the band to Automatic and then adjust the tuning slug for the selected preset. There is no way to know where the preset is tuned to except by turning it and tryng to identify the station. It may take several turns of the tuning slug. If the main tuning it set to the AM station you want to set the preset for, you can switch between Automatic and the Standard Broadcast band to check if you have the right station selected (i.e. by comparing what broadcast you hear).

@@jefftranter Thanks - I will give that a try

If you remove the cover with the preset buttons, behind it are 6 variable capacitors. You turn the capacitor shaft corresponding to the button that is pressed in to tune to the station you want. The band selector needs to be on "Automatic" to use the presets.

Thanks for the quick reply.

The HP-23A model does not use any fuses, only a circuit breaker. I did not change it. The older HP-23 model did use fuses.

There was no support for dialling or even going off hook - you needed to dial with a telephone and leave it off hook during the call. It could even be damaged by ringing voltage if was left on and the phone rang.

I don't have an original manual for the SB-110. You may be able to find a manuak that can be downloaded from the Internet or purchased from vendors like manualman.com

The manual lists it as Heathkit part number 417-828 and type E-304. It is a FET. A transistor substitution guide lists the 2N5486 as equivalent.

My all2.bin ROM image includes Microsoft Basic, which fits in 4K. It is roughly equivalent to 8K BASIC on the 6502. It has PEEK and POKE. INP and OUT are i/o port functions that only apply to processors that have i/o ports like the 8080 and Z80. I'm not aware of an 8K version of Microsoft Basic for the 6800. If you know of a source, point me to it.

Yes, NiMH batteries could be used in place of the original NiCd type. They produce the same voltage and have a greater capacity. In that case you should not connect the built-in charger as it would not correctly charge NiMH batteries and could overcharge and damage them.

I have not, but these old signal generators aren't marked very accurately for frequency, so using a frequency counter is a good way to check the frequency is the cases where it is important.

That could certainly be the problem. It is common for electrolytic capacitors like that one to fail after many years. You can find copies of the Heathkit manual on-line and it has a troubleshooting section that may be helpful.

It has composite video out and I connected it directly to a monitor that accepts composite video input.

@@jefftranter on the back? same model.. mine has alligator clips.

@@Johnh-r2x Yes, I had to connect the video output cable to a suitable connector for the monitor, i.e. an RCA phono plug.

@@jefftranter what was plugged into the AC input on the right side?

@@Johnh-r2x I was just using the AC outlet on the unit as a convenient way to power the monitor.

I believe the windowing system and widget set exist in BIOS. So MacOS is not necessarily running.

@@thirstyCactus The classic Mac doesn’t work anything like a PC - there’s no BIOS per se, what there is is a set of software modules (usually called ‘managers’ - so, the Window Manager, the Serial Manager, etc) with the majority of them being resident in ROM, but some of them (or portions of them) are loaded into RAM at boot. These ROM based modules can also be patched at boot, so things as small as a single function can be updated by new code. Collectively, these are referred to as the Toolbox. There’s also a module referred to as the OS which handles low-level device drivers. All of this is interdependent on each other - in order for one section to be running, it generally means other sections are running also. So, basically, if you’re seeing the GUI on screen, then the Toolbox is running, and if there’s any disk or serial IO occurring then the low-level OS is running also. FWIW, this ROM based approach is how they got a whole GUI & OS running on a machine with only 128k of RAM and still had enough left over for running an application.

​@@darkwinter6028 The Mac Toolbox with the managers is the BIOS. It's just more elaborate and the terminology is different. In x86 PC world, the BIOS was originally not just a bootloader and settings utility but it had the drivers for working with the hardware. Apps running bare-metal on the PC would call BIOS routines via the x86's INT syscall/software interrupt mechanism to read/write the disk, put stuff on the screen, etc. The Mac is similar where the A-line trap instructions would invoke toolbox calls. Except instead of just reading the disk and doing simple screen output like on the IBM ROM BIOS, there were higher-level concepts such as resources, windows, the mouse pointer, etc. I see those as the Mac developers' concept of the "hardware drivers" for a GUI machine. Nowadays on a modern x86 PC it sounds archaic to have stuff like the window manager in ROM since every OS does it differently, plus any good OS (Windows, Linux, etc) does not use the BIOS routines even for disk I/O after the initial parts of boot. But the IBM BIOS had a few pretty sophisticated "OS-type" features, such as the clock interrupt, printing, display including fixed-width "fonts" (the INT 1Fh character table), and even the INT 18h "execute BASIC" call. So I would say that the Mac's architecture was a kind of unusual intermediate step between an OS and userspace fully in RAM and the bare-metal IBM PC app style where a program calls the BIOS for all I/O. If you think about the transition between the single-app Mac execution model and MultiFinder/System 7, it's basically the same as the "coexistence" between Minix and the Toolbox stuff you referred to. Before MultiFinder, only one app ran at once. With MultiFinder or System 7, you had cooperative multitasking and the way the system worked was fairly different than was anticipated in the Toolbox ROM. Interestingly though, many of the things in the ROM such as the memory manager ended up sort of applied twice over when running MultiFinder or System 7, once at the system level and once at the app level. For example, the memory manager handles allocation of each application zone within the overall system RAM, but then after a context switch into an app, the global variables are changed so that the memory manager is used to allocate storage from the application heap zone that was previously allocated by the memory manager in the "OS" context. So my point is that if you know how to use the managers, you can sort of reuse them in contexts not originally considered as long as you set up the global variables correctly. I suspect it would be possible, for example, to have a totally different, even preemptively multitasked OS that still calls into ROM to draw the GUI on the screen using the window manager, menu manager, etc. Is this how A/UX does it? I wouldn't be surprised if it reused the ROM routines like that, but I also wouldn't be surprised if it just had its own version in RAM.

I didn't port it - this was an official release of Minix for the Mac.

@@jefftranter That's interesting - thank you. You always have interesting videos.