SuperHermes Questions

[Pr0f]

Well - still trying to get my SuperHermes to talk to a PC Keyboard. I even have one that's known to work with SuperHermes Lite - so shoud be ok for SuperHermes too.

It seems that F1 keypress is detected sometimes, the manual states that F1/F2 keys are the only ones recognised before the extensions are loaded.

I have the SuperHermes Floppy disk in the drive and it's booting from that - loading the extensions - but I still have no keyboard.

So questions:

1) Do the IPCDisable and IPCEnable commands survive a power cycle (is the state stored in the EEPROM?
2) Does the key lock feature require the switch to be closed or open to lock the keyboard - in other words - if I have nothing connected to the 2 pin header P7, will the keyboard be locked or unlocked? The manual suggests unlocked, but seeking confirmation.

Until I can get a floppy wired up to my Gold card, I can't see what's in the boot file for the SuperHermes, unless I can persuade Qemulator to work with a DD floppy.

[Derek_Stewart]

Hi,

The Superhermes F1/F2 key on the Superhermes keyboard, was always0 temperamental, I had it working sometimes, but on most cases, it did not work.

I relied the AUTO_TK2F1 and load the Superhermes keyboard driver, from the boot device, disk drive or hard disk.

Probably the best idea was to use the ROM version of the Superhermes Driver. With the Romdisq, roms coukd added to the system easily, but not relaveng now, Romdisq seems lost.

I think the IPCENABLE is the normal default, which can be changed, with the IPCDISABLE command on boot up.

The key lock needs P7 to be closed, or a keyswitch in the lock position.

There was a program called "storeSH" by Phil Borman can save Superhermes defaults to the EEPROM:

storesh.zip

(1.82 KiB) Downloaded 117 times

There seems to be no documentation.

[Pr0f]

I think I got some or all of my answers from testing Qemulator with the floppy drive. I was able to read and copy the contents of my "SuperHermes" floppy - only to find it was more likely a Hermes version - their are no country specific files, and the main bin file is much smaller than the 6K one I have archived on my PC's folders.

So whilst the boot floppy loads, runs and detects a Hermes - it lacks the actual code to drive the keyboard - it could have saved me taking the Aurora, SGC and Qubide in and out of the case a few times to check the hardware!!

I will create a CF card image and boot from that - as that's reliably detecting the media and I should be able to copy files to it.

Hopefully a few steps closer to getting this project put to bed.

[BSJR]

So whilst the boot floppy loads, runs and detects a Hermes - it lacks the actual code to drive the keyboard - it could have saved me taking the Aurora, SGC and Qubide in and out of the case a few times to check the hardware!!

I use the IPCext_bin (from Hermes) in my boot to test if Hermes (2.xx) or SuperHermes (3.xx) is there.
Only then do I load the right language _bin for S'Hermes which can be USA or NL in my case.
These can be found on https://dilwyn.theqlforum.com/docs/manuals/index.html
Go down to "TF Services Manuals" for pdfs, docs and drivers.

F1 or F2 can only be used once before the SH-driver is loaded.
Also an SMSQ/E RESET command on a SH-keyboard can freeze the machine so I always do :PAUSE 50:RESET: as a direct command to avoid this.

BSJR

[Pr0f]

Resurrecting this thread as I am looking at the SuperHermes PIC with a view to recreating it.

I know we have not got the source code, but we do have the manual that tells us which calls are used for Hermes, and for SuperHermes.

So my questions are these:

1) From what I can tell - the SuperHermes reads the PC keyboard but does not actually try and translate the pc keyboard key scan codes in the SuperHermes itself - it looks like it may pass them over the IPC communication path to the QL for the driver of SuperHermes to process - looking for confirmation on that - and if anyone has ever spied on the wire to see what the format of those communications actually is?

2) I don't have a SuperHermes Lite anymore - is the code within the PIC the same? - and the only difference being that the majority of support components are not populated - so no additional serial ports or NVRAM - only the Hermes improvements to the original IPC and the PS/2 Keyboard being supported?

[Popopo]

Also interested about this thread. I have been studying how it works in general.
My idea is to create (to try) a replacement, but only focused in the keyboard by now.

[Pr0f]

I am working on a 3 chip design - a couple of TTL chips and a 28 pin PIC that will fit in the 40 pin footprint of the IPC chip.

By way of a teaser - these are the goals of the replacement:

Compatible with all HERMES and most of the SuperHemes extensions.
Interrupt driven sound that doesn't affect serial reception
Interrupt driven serial that uses the hardware UART on the PIC - but uses the same technique of the original IPC/Hermes to decide which port it's receiving for, it may offer the possibility of AutoBaud.
An LED output
Improved Keyboard scanning - again interrupt based, but with polling too.
PS/2 Keyboard support - but offering a better compatability with modern PS/2 keyboards - in particular my Belkin KVM switch!
A smaller 256 byte NV RAM - as this is on chip on the PIC already.
A tunable clock output (will repurpose the delay setting to set clock frequency)
A non dedicated 8 input mux
Baud rate independant of BaudX4, and 11MHz crystal, which is no longer used.

What's not included:

Ser3,4,5 and 6
The mouse support
Most of the extra lines released by Hermes from the original IPC

Since the source code for the SuperHermes is no longer around - this will be a 'from the ground up' design - but using a lot of the improvement ideas that Hermes provided - except I will take full advantage of the superior on chip hardware that a mid range PIC has to offer.