Hey all! Radience32 directed me to this forum off his channel. I have both an HP 200LX (Double-speed 8mb) and an 100LX (Stock 1mb).

I heard there was plans to do a PCMCIA card that links to an ESP32 or similar for Wifi... and I see there's some onus for sound, parallel port, and maybe storage? A "dream card" would be wifi, sound, and storage off an SD card. Adafruit has 128MB microSD cards (MB, not GB), strangely enough. Gotta back up that RAM.

STrRedWolf wrote on 2021-12-29, 22:13:

Hey all! Radience32 directed me to this forum off his channel. I have both an HP 200LX (Double-speed 8mb) and an 100LX (Stock 1mb).

I heard there was plans to do a PCMCIA card that links to an ESP32 or similar for Wifi... and I see there's some onus for sound, parallel port, and maybe storage? A "dream card" would be wifi, sound, and storage off an SD card. Adafruit has 128MB microSD cards (MB, not GB), strangely enough. Gotta back up that RAM.

Check out this thread: PCMCIA Sound Cards
The user who's working on it's nickname is yyzkevin

Also, Your 8MB 200LX, is it a 1MB or 2MB base model, and what kind of memory upgrade do you have ?
IS it 2MB model, with a 6MB expansion board fitted onto the motherboard ?

Cheers,
Radiance

Has anyone else messed with the crystal selection bits of the system control register? I haven't run into any mention of it, but it certainly seems like it might be usable for either soft-overclocking a stock system, or further overclocking a crystal-upgraded unit.

1------------------------------------------------------------------------------------------
2-1Eh    R/W     System Control Register
3                bits 7-6 speaker volume
4                      = 00 off (0V)
5                      = 01 soft (3V)
6                      = 10 medium (5V)
7                      = 11 loud (8V)
8                bits 5-4 crystal speed selection
9                      = 00 10.738636 MHz
10                      = 01 15.836773 MHz
11                      = 10 21.477272 MHz
12                      = 11 31.673550 MHz
13                bit 3      unused
14                bit 2 = 1  display on
15                bit 1 = 1  unit has been in backup mode
16                bit 0 = 1  CPU shutdown (set only)
17------------------------------------------------------------------------------------------

The default setting for this register with my stock 200LX is 0xDD, corresponding with the 15.836773 MHz clock selection, and with which Jim Leonard's TOPBENCH utility reports the following:

1TOPBENCH | 16-bit real-mode x86 Benchmarking Suite | Version 0.40a
2Score:                  9
3Memory:                 2178 µs
4Effective addressing:   1050 µs
5Opcode exercise:        732 µs
6Vid adapter speed:      460 µs
73DGame opcode exercise: 709 µs

With a setting of 0xFD, TOPBENCH reports the following:

1TOPBENCH | 16-bit real-mode x86 Benchmarking Suite | Version 0.40a
2Score:                  22
3Memory:                 958 µs
4Effective addressing:   445 µs
5Opcode exercise:        310 µs
6Vid adapter speed:      196 µs
73DGame opcode exercise: 310 µs

A consequence of the latter setting is behavior similar to that of upgrading the crystal. That is, rates relevant to the display, PIT and serial UART, among others, are affected. It's seemingly the opposite behavior of the hardware upgrade though, where instead of the affected rates needing to be halved to compensate, they may instead need to be doubled. Still experimenting with this...

Cloudschatze wrote on 2021-12-29, 23:33:

Has anyone else messed with the clock selection bits of the system control register? I haven't run into any mentions of it, but […]
Show full quote

Has anyone else messed with the clock selection bits of the system control register? I haven't run into any mentions of it, but it certainly seems like it might be usable for either soft-overclocking a stock system, or further overclocking a crystal-upgraded unit.

Copy code to clipboard

1------------------------------------------------------------------------------------------
2-1Eh    R/W     System Control Register
3                bits 7-6 speaker volume
4                      = 00 off (0V)
5                      = 01 soft (3V)
6                      = 10 medium (5V)
7                      = 11 loud (8V)
8                bits 5-4 crystal speed selection
9                      = 00 10.738636 MHz
10                      = 01 15.836773 MHz
11                      = 10 21.477272 MHz
12                      = 11 31.673550 MHz
13                bit 3      unused
14                bit 2 = 1  display on
15                bit 1 = 1  unit has been in backup mode
16                bit 0 = 1  CPU shutdown (set only)
17------------------------------------------------------------------------------------------

The default setting for this register with my stock 200LX is 0xDD, corresponding with the 15.836773 MHz clock selection, and with which Jim Leonard's TOPBENCH utility reports the following:

Copy code to clipboard

1TOPBENCH | 16-bit real-mode x86 Benchmarking Suite | Version 0.40a
2Score:                  9
3Memory:                 2178 µs
4Effective addressing:   1050 µs
5Opcode exercise         732 µs
6Vid adapter speed:      460 µs
73DGame opcode exercise: 709 µs

With a setting of 0xFD, TOPBENCH reports the following:

Copy code to clipboard

1TOPBENCH | 16-bit real-mode x86 Benchmarking Suite | Version 0.40a
2Score:                  22
3Memory:                 958 µs
4Effective addressing:   445 µs
5Opcode exercise         310 µs
6Vid adapter speed:      196 µs
73DGame opcode exercise: 310 µs

A consequence of the latter setting is behavior similar to that of upgrading the crystal. That is, rates relevant to the display, PIT and serial UART, among others, are affected. It's seemingly the opposite behavior of the hardware upgrade though, where instead of the affected rates needing to be halved to compensate, they may instead need to be doubled. Still experimenting with this...

Very interesting 😀
What do you think would happen on a doublespeed crystal system ?

Terrence

Cloudschatze wrote on 2021-12-29, 23:33:

Has anyone else messed with the clock selection bits of the system control register? I haven't run into any mentions of it, but […]
Show full quote

Has anyone else messed with the clock selection bits of the system control register? I haven't run into any mentions of it, but it certainly seems like it might be usable for either soft-overclocking a stock system, or further overclocking a crystal-upgraded unit.

Copy code to clipboard

1------------------------------------------------------------------------------------------
2-1Eh    R/W     System Control Register
3                bits 7-6 speaker volume
4                      = 00 off (0V)
5                      = 01 soft (3V)
6                      = 10 medium (5V)
7                      = 11 loud (8V)
8                bits 5-4 crystal speed selection
9                      = 00 10.738636 MHz
10                      = 01 15.836773 MHz
11                      = 10 21.477272 MHz
12                      = 11 31.673550 MHz
13                bit 3      unused
14                bit 2 = 1  display on
15                bit 1 = 1  unit has been in backup mode
16                bit 0 = 1  CPU shutdown (set only)
17------------------------------------------------------------------------------------------

The default setting for this register with my stock 200LX is 0xDD, corresponding with the 15.836773 MHz clock selection, and with which Jim Leonard's TOPBENCH utility reports the following:

Copy code to clipboard

1TOPBENCH | 16-bit real-mode x86 Benchmarking Suite | Version 0.40a
2Score:                  9
3Memory:                 2178 µs
4Effective addressing:   1050 µs
5Opcode exercise         732 µs
6Vid adapter speed:      460 µs
73DGame opcode exercise: 709 µs

With a setting of 0xFD, TOPBENCH reports the following:

Copy code to clipboard

1TOPBENCH | 16-bit real-mode x86 Benchmarking Suite | Version 0.40a
2Score:                  22
3Memory:                 958 µs
4Effective addressing:   445 µs
5Opcode exercise         310 µs
6Vid adapter speed:      196 µs
73DGame opcode exercise: 310 µs

A consequence of the latter setting is behavior similar to that of upgrading the crystal. That is, rates relevant to the display, PIT and serial UART, among others, are affected. It's seemingly the opposite behavior of the hardware upgrade though, where instead of the affected rates needing to be halved to compensate, they may instead need to be doubled. Still experimenting with this...

Also, do you notice any speed difference when executing applications ?
Or is the faster benchmark score just incorrect because of wrong timers used etc ???

Terrence

radiance32 wrote on 2021-12-30, 00:18:

Also, do you notice any speed difference when executing applications ?

There's definitely a speed difference, but the undesirable consequential behaviors make it sort-of pointless, unless those can be rectified.

I'm not sure what the behavior might be with a hardware-modded unit. The MS-DOS debug utility can be used to set the indexed register, if you want to test:

1-o 22 1e
2-o 23 fd
3-q

I/O against a CompactFlash card in the PCMCIA slot is similarly improved.

Stock/default (1Eh, 0xDD):

1DiskTest, by James Pearce.  Version 2.3
2
3Preparing drive...
4Configuration: 4096 KB test file, 256 IOs in random tests.
5
6Write Speed         : 223.34 KB/s
7Read Speed          : 409.60 KB/s
88K random, 70% read : 9.2 IOPS
9Sector random read  : 11.1 IOPS
10
11Average access time (includes latency and file system overhead), is 90ms.

Tweaked (1Eh, 0xFD):

1DiskTest, by James Pearce.  Version 2.3
2
3Preparing drive...
4Configuration: 4096 KB test file, 256 IOs in random tests.
5
6Write Speed         : 811.09 KB/s
7Read Speed          : 957.01 KB/s
88K random, 70% read : 20.6 IOPS
9Sector random read  : 28.3 IOPS
10
11Average access time (includes latency and file system overhead), is 35ms.

Cloudschatze wrote on 2021-12-30, 03:53:

I/O against a CompactFlash card in the PCMCIA slot is similarly improved. […]
Show full quote

I/O against a CompactFlash card in the PCMCIA slot is similarly improved.

Stock/default (1Eh, 0xDD):

Copy code to clipboard

1DiskTest, by James Pearce.  Version 2.3
2
3Preparing drive...
4Configuration: 4096 KB test file, 256 IOs in random tests.
5
6Write Speed         : 223.34 KB/s
7Read Speed          : 409.60 KB/s
88K random, 70% read : 9.2 IOPS
9Sector random read  : 11.1 IOPS
10
11Average access time (includes latency and file system overhead), is 90ms.

Tweaked (1Eh, 0xFD):

Copy code to clipboard

1DiskTest, by James Pearce.  Version 2.3
2
3Preparing drive...
4Configuration: 4096 KB test file, 256 IOs in random tests.
5
6Write Speed         : 811.09 KB/s
7Read Speed          : 957.01 KB/s
88K random, 70% read : 20.6 IOPS
9Sector random read  : 28.3 IOPS
10
11Average access time (includes latency and file system overhead), is 35ms.

Are you sure the read/write speed is better, or does it just report better results due to the timer to calculate them running faster ?
If you say copy a large file, and manually measure the speed with a stopwatch, does it really copy the whole thing that much faster ???
Seems strange as the write speed reported is nearly 4x as fast, not 2x...

Radiance

Cloudschatze wrote on 2021-12-30, 00:37:

There's definitely a speed difference, but the undesirable consequential behaviors make it sort-of pointless, unless those can b […]
Show full quote

radiance32 wrote on 2021-12-30, 00:18:

Also, do you notice any speed difference when executing applications ?

There's definitely a speed difference, but the undesirable consequential behaviors make it sort-of pointless, unless those can be rectified.

I'm not sure what the behavior might be with a hardware-modded unit. The MS-DOS debug utility can be used to set the indexed register, if you want to test:

Copy code to clipboard

1-o 22 1e
2-o 23 fd
3-q

Maybe you can adapt the clkup31 or clkup32 to negate the differences ?

Radiance

Cloudschatze wrote on 2021-12-30, 00:37:

There's definitely a speed difference, but the undesirable consequential behaviors make it sort-of pointless, unless those can b […]
Show full quote

radiance32 wrote on 2021-12-30, 00:18:

Also, do you notice any speed difference when executing applications ?

There's definitely a speed difference, but the undesirable consequential behaviors make it sort-of pointless, unless those can be rectified.

I'm not sure what the behavior might be with a hardware-modded unit. The MS-DOS debug utility can be used to set the indexed register, if you want to test:

Copy code to clipboard

1-o 22 1e
2-o 23 fd
3-q

I tried it on one of my 32MHz crystal machines, with the clkup32.sys loaded,
and I see no difference, everything behaves normal... (eg the system runs as it always runs with a CPU clock of 16MHz)
I guess the 32MHz crystal does what you're trying to do already.

I'll test it with a non upgraded machine too and see if the PCMCIA IO speed is the same between a hardware upgraded machine and a stock machine with the values set...

Radiance

radiance32 wrote on 2021-12-30, 05:01:

Are you sure the read/write speed is better, or does it just report better results due to the timer to calculate them running faster ?
If you say copy a large file, and manually measure the speed with a stopwatch, does it really copy the whole thing that much faster ???

~21.27 seconds and ~18.23 seconds, respectively, as concerns the copy of a 4MB file from the CompactFlash card to the internal RAM disk. So, slightly faster, but certainly not the difference suggested by the DiskTest results.

This whole exercise is a moot point for me though - I've run the numbers, and there doesn't appear to be any way to get a 38400 bps serial rate when using either of the two "faster" soft changes to the crystal selection bit.

Cloudschatze wrote on 2021-12-30, 05:25:

radiance32 wrote on 2021-12-30, 05:01:

Are you sure the read/write speed is better, or does it just report better results due to the timer to calculate them running faster ?
If you say copy a large file, and manually measure the speed with a stopwatch, does it really copy the whole thing that much faster ???

~21.27 seconds and ~18.23 seconds, respectively, as concerns the copy of a 4MB file from the CompactFlash card to the internal RAM disk. So, slightly faster, but certainly not the difference suggested by the DiskTest results.

This whole exercise is a moot point for me though - I've run the numbers, and there doesn't appear to be any way to get a 38400 bps serial rate when using either of the two "faster" soft changes to the crystal selection bit.

Are you sure you don't want me to send you a 32MHz crystal ? It's really worth it 😀
After a few days you'll be thinking why you did'nt install one sooner 😀

Radiance

Cloudschatze wrote on 2021-12-30, 05:25:

radiance32 wrote on 2021-12-30, 05:01:

Are you sure the read/write speed is better, or does it just report better results due to the timer to calculate them running faster ?
If you say copy a large file, and manually measure the speed with a stopwatch, does it really copy the whole thing that much faster ???

~21.27 seconds and ~18.23 seconds, respectively, as concerns the copy of a 4MB file from the CompactFlash card to the internal RAM disk. So, slightly faster, but certainly not the difference suggested by the DiskTest results.

This whole exercise is a moot point for me though - I've run the numbers, and there doesn't appear to be any way to get a 38400 bps serial rate when using either of the two "faster" soft changes to the crystal selection bit.

I think your performance results aren't right. Maybe the timer to calculate them is off...
If it is easy to double the speed via software, this simple do double-speed the hornet SOC, someone would have discovered this during the last 3 decades, I'm sure, no ?

It might be interesting to see if I can increase the PCMCIA IO speed though on my doublespeed system with one of the options,
but i'll also have to update the cklup32 driver

Terrrence

radiance32 wrote on 2021-12-30, 05:09:

I tried it on one of my 32MHz crystal machines, with the clkup32.sys loaded,
and I see no difference, everything behaves normal... (eg the system runs as it always runs with a CPU clock of 16MHz)

Turns-out the "CLKUP" drivers already configure the crystal speed selection bits for the 31.673550 MHz setting as part of their routine, which makes sense.

radiance32 wrote on 2021-12-30, 09:54:

I think your performance results aren't right. Maybe the timer to calculate them is off...

The timer is definitely off, which probably explains everything. With the stock crystal and speed selection settings, TCLK is 1.193182 MHz. With the stock crystal and modified speed selection, TCLK drops by exactly half, to 0.922004 MHz. Consequently, the speed perception differences, as well as the slight differences with the timed file copy, are likely just the result of the DMA refresh being affected.

Ah, well. This was interesting for a minute or two. 😀

That said, there are registers for directly altering the DMA refresh rate and various system wait states, so another avenue for minor, software-based speed tweaking yet exists...

If it is easy to double the speed via software, this simple do double-speed the hornet SOC, someone would have discovered this during the last 3 decades, I'm sure, no ?

Most likely, but having personally discovered a number of "hidden" settings and functions for even older systems, this sort of thing isn't exactly inconceivable either.

radiance32 wrote on 2021-12-29, 22:27:

Check out this thread: PCMCIA Sound Cards The user who's working on it's nickname is yyzkevin […]
Show full quote

Check out this thread: PCMCIA Sound Cards
The user who's working on it's nickname is yyzkevin

Also, Your 8MB 200LX, is it a 1MB or 2MB base model, and what kind of memory upgrade do you have ?
IS it 2MB model, with a 6MB expansion board fitted onto the motherboard ?

Cheers,
Radiance

It's actually a 4MB base model. I haven't had a chance to open it up and look in it -- I bought it "as is" on eBay (the person who sold it didn't know about the double-speed upgrades, and thought it was broken) and was able to "fix" it. 😀 Now if I can do long file names, it'll be a nice little machine for sneak-writing some stories.

STrRedWolf wrote on 2022-01-03, 11:56:

radiance32 wrote on 2021-12-29, 22:27:

Check out this thread: PCMCIA Sound Cards The user who's working on it's nickname is yyzkevin […]
Show full quote

Check out this thread: PCMCIA Sound Cards
The user who's working on it's nickname is yyzkevin

Also, Your 8MB 200LX, is it a 1MB or 2MB base model, and what kind of memory upgrade do you have ?
IS it 2MB model, with a 6MB expansion board fitted onto the motherboard ?

Cheers,
Radiance

It's actually a 4MB base model. I haven't had a chance to open it up and look in it -- I bought it "as is" on eBay (the person who sold it didn't know about the double-speed upgrades, and thought it was broken) and was able to "fix" it. 😀 Now if I can do long file names, it'll be a nice little machine for sneak-writing some stories.

If you can get long filenames working, let me know about it please, I'm interested in knowing how too 😀

Radiance

Okay, newbie question with double-speed.

I'm trying to use another telecom program, completely outside of the native software because... it looks like it's not quite compatible with the terminal capabilities that Linux has (even with vt100). And I'm having associated problems:

• RBComm sits there and does nothing, even though I have the ports set right.
• Bananacom recognizes even an ESP32-based modem... but freezes right afterwards and requires a hard reset (CONTROL-SHIFT-ON).

Any ideas? I'm about to double-check with my 100LX, which is stock.

STrRedWolf wrote on 2022-01-14, 12:55:

Okay, newbie question with double-speed. […]
Show full quote

Okay, newbie question with double-speed.

I'm trying to use another telecom program, completely outside of the native software because... it looks like it's not quite compatible with the terminal capabilities that Linux has (even with vt100). And I'm having associated problems:

• RBComm sits there and does nothing, even though I have the ports set right.
• Bananacom recognizes even an ESP32-based modem... but freezes right afterwards and requires a hard reset (CONTROL-SHIFT-ON).

Any ideas? I'm about to double-check with my 100LX, which is stock.

Are you running the clkup32.sys ?
What kind of doublespeed crystal do you have ? the 32MHz one or the 31.64 MHz crystal ?
Try it on your stock system and see if it behaves the same...

I don't know a lot about it, but the doublespeed options make your UART baud rate setting appear 2x as fast,
that's why the clkup32.sys corrects this, and there might be an incompatibility there...
You should try it on a non-doublespeed system to make sure...

Terrence

radiance32 wrote on 2022-01-15, 03:58:

Are you running the clkup32.sys ? What kind of doublespeed crystal do you have ? the 32MHz one or the 31.64 MHz crystal ? Try it […]
Show full quote

Are you running the clkup32.sys ?
What kind of doublespeed crystal do you have ? the 32MHz one or the 31.64 MHz crystal ?
Try it on your stock system and see if it behaves the same...

I don't know a lot about it, but the doublespeed options make your UART baud rate setting appear 2x as fast,
that's why the clkup32.sys corrects this, and there might be an incompatibility there...
You should try it on a non-doublespeed system to make sure...

I was using the dspeed.com driver, so let me open things up here... I got the 31.64 MHz crystal (the exact doubled). The RAM upgrade is a Times PC8MB according to the board.

So I'll swap to the clkup31.sys driver then, see if that helps.

A few updates.

Testing with CLKUP31.SYS and on the stock HP 100LX resulted in... the same issues. Bananacom freezes up, and RBComm works but it doesn't have a good terminal emulation.

Guess I'll have to use Kermit then. 😉 I did get in touch with Bananacom's author, who's on Reddit, to see about getting the latest version or the source code.

That said... my HP200LX has seen better days. The standoffs inside holding the bottom shell to the top shell have broken off, so I'm repairing them by 3D printing new standoffs and supergluing them (hint: the screws are M2 screws with hex ends, or a Torx T6). To be honest, I should of made a small jig to hold the backplate in place and screwed the standoffs through that for a better fit.

Hmmm... should look into more broken HP palmtops...