• Spring 2024 meetup in Calgary - tentative date Saturday, April 20/2024. Other regions are also discussing meet ups. If you want one in your area get going on organizing it! discussion
  • We are having email/registration problems again. Diagnosis is underway. New users sorry if you are having trouble getting registered. We are exploring different options to get registered. Contact the forum via another member or on facebook if you're stuck. Update -> we think it is fixed. Let us know if not.
  • Spring meet up in Ontario, April 6/2024. NEW LOCATION See Post #31 Discussion NEW LOCATION

parallels

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
Another RPN fan here. Have a 41CV on my phone and a real 15C in my drawer.
I have an app on my Android called Free42 which is almost as good as my HP 32S II sitting beside me here.

I had a 41C app on my phone but deleted it cuz it was crashing too often. I actually programmed a real 41C to play chess many years ago. Entered an HP contest with it. Didn't even place. I think the judges had no idea and/or didn't believe it. The program that won was rinky dink by comparison. Still pissed about that 50 years later.

On the other hand, that program taught me to think in octal. Clearly superior to both metric and Imperial. If only we humans didn't include our thumbs when we first learned to count. It might have even been good enough to get the Americans to dump imperial. Of course, some might say hexadecimal is better still.

Have a real HP11 in the barn, and a real HP15 in the house. My first HP was a 45. Still have it and it still works but don't use it or the slide rule it replaced that sits next to it.

Gotta find that Free42 app and try that tomorrow.

Amazing stuff. Thanks for the memories.
 

Dabbler

ersatz engineer
I'm bilingual RPN and algebraic. Use them interchangeably. +1 on Octal. I like Hexadecimal as well, especially for Byte arithmetic,.
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
I have an app on my Android called Free42 which is almost as good as my HP 32S II sitting beside me here.
Couldn't wait. Tried it out tonight. Decided to plop down 12 bucks for the plus version. Same programmable calculator with additional features. Liking it so far.
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
Ever tried programming in FORTH?

Yes. About 50 years ago. I liked it at the time because of its stack structure like RPN. It was also very low level - almost assemblerish.

I used to tell people that FORTH and RPN work the same way our brains really work. Procedural. They don't work the way we think our brains work.
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
@jcdammeyer my cousin was one of the big FORTH gurus. I left it all to him.... I did so much assembly I had to be fluent in binary/octal/hex.

I think you would have liked FORTH. Very much LIKE assembly language. But wasn't.

Personally, I LOVED assembly language. Did more of that than any other. Prolly another reason I liked Octal & Hex too.
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
@Dabbler @jcdammeyer Another reason I liked Assembler was that I started out using raw machine language. VERY PAINFUL. Assembly saved me from going insane...... Or did it.......

You guys might enjoy this too. I actually wrote that HP chess program in a mixture of pseudo assembly and Fortran. Then I developed a manual compiler to convert the assembly/Fortran into the Hp calculator language (I forget what it was called). The assembly side handled the board, the pieces, the moves, and the weighting, and the Fortran side handled the logic, workflow, and decision making.

I think HP's calculator language used a varient of Forth at its core.
 

jcdammeyer

John
Premium Member
Time for some pictures. This is the only one I have. It's our kitchen reno floor plan. Z80 CP/M system using a graphics card of my own design. Photos below.

The drawing of the lines etc. were lower level FORTH words. Those lines were turned into things like the fridge and stove which were also FORTH words. Where they were put on the screen was something like
X
Y
FRIDGE

Once I pull out the 8" disk system again I might still have the source code on a floppy somewhere.

GraphicsDrawing.jpg


NEC_D7220_GraphicsF.jpg



NEC_D7220_GraphicsB.jpg
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
Time for some pictures. This is the only one I have. It's our kitchen reno floor plan. Z80 CP/M system using a graphics card of my own design. Photos below.

The drawing of the lines etc. were lower level FORTH words. Those lines were turned into things like the fridge and stove which were also FORTH words. Where they were put on the screen was something like
X
Y
FRIDGE

Once I pull out the 8" disk system again I might still have the source code on a floppy somewhere.

View attachment 25242


View attachment 25240



View attachment 25241

NICE!!!

Looks like S100 boards.....

Threw all that stuff of mine away when we moved to the farm.

Prolly threw out the chess program then too.

(Insert image of old man crying his eyes out here).
 

jcdammeyer

John
Premium Member
NICE!!!

Looks like S100 boards.....

Threw all that stuff of mine away when we moved to the farm.

Prolly threw out the chess program then too.

(Insert image of old man crying his eyes out here).
Yes. S100 boards. I currently have working:
Z80 Ithica with 256K RAM paged into the 62K workable image along with two 8" dual sided double density drives.
CP/M-86 System with 5.25" floppy and 20MB hard using an 80186 processor.
OS9-68K with 1MB ram, 5,25" floppy and replaced 20MB Rodime hard drive with BeagleBone Black module and MFM cape.

Have not yet got the MP/M-86 system up because of what is below.

I too threw out stuff a few years ago that I now regret. Seems like 8" Shugart disk drives go for $350US nowadays.
 

jcdammeyer

John
Premium Member
OS9-68K with 1MB ram, 5,25" floppy and replaced 20MB Rodime hard drive with BeagleBone Black module and MFM cape.
This was the tough one. Originally CP/M-68K but those manuals and disks were part of that throw away process.
In either case back in 1986 just before #1 son was born I was converting that system to OS9-68K. It booted from the floppy with a G command to the debug monitor in ROM.
Trouble is, no floppy. And the hard drive had the OS but it had trouble coming up to speed. Eventually the MFM was able to recover 99% of the information from that drive.
So how to boot an OS9 system that can't boot from the hard drive and you don't have a floppy.
1. Two different emulators running on a PC. One that can work with floppy and hard drive images that aren't exactly the same as the physical device and one that can copy files from a proper hard drive image to a windows folder.
2. A working Z80 system that can accept the SD VFW-III board that is connected to the 5.25" floppy and is what is used in the OS9 system.
3. A working copy of the original Turbo Pascal 1.0 running on the Z80 system.
a) write a monitor to work with the VFW-III including reading/writing sectors.
b) Be able to download sector by sector images of a floppy to transfer to the 5.25". This was written in Turbo Pascal.
c) Write a program that translates the emulator strange floppy image into a proper binary floppy image. (also in Turbo Pascal).
4. Rewrite the Boot Eprom code recovered from the hard drive to check for hard drive and boot from it if there. That was never done back in 1986.

When all was said and done I now have the OS9 system booting from floppy or MFM hard drive. The NICAD battery for the clock board had leaked and damaged some of each of the MFIO boards. Got one working. Found a bug in the original clock support code and fixed that. Dealt with Millenium bug where 31DEC1999 at 23:59:59 does not roll over to 2000. Created strange number.
Now files have proper dates for 2022.

All this was done in M68000 assembler. The Boot EPROM and the device drivers for booting from the hard and the clock support.
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
This was the tough one. Originally CP/M-68K but those manuals and disks were part of that throw away process.
In either case back in 1986 just before #1 son was born I was converting that system to OS9-68K. It booted from the floppy with a G command to the debug monitor in ROM.
Trouble is, no floppy. And the hard drive had the OS but it had trouble coming up to speed. Eventually the MFM was able to recover 99% of the information from that drive.
So how to boot an OS9 system that can't boot from the hard drive and you don't have a floppy.
1. Two different emulators running on a PC. One that can work with floppy and hard drive images that aren't exactly the same as the physical device and one that can copy files from a proper hard drive image to a windows folder.
2. A working Z80 system that can accept the SD VFW-III board that is connected to the 5.25" floppy and is what is used in the OS9 system.
3. A working copy of the original Turbo Pascal 1.0 running on the Z80 system.
a) write a monitor to work with the VFW-III including reading/writing sectors.
b) Be able to download sector by sector images of a floppy to transfer to the 5.25". This was written in Turbo Pascal.
c) Write a program that translates the emulator strange floppy image into a proper binary floppy image. (also in Turbo Pascal).
4. Rewrite the Boot Eprom code recovered from the hard drive to check for hard drive and boot from it if there. That was never done back in 1986.

When all was said and done I now have the OS9 system booting from floppy or MFM hard drive. The NICAD battery for the clock board had leaked and damaged some of each of the MFIO boards. Got one working. Found a bug in the original clock support code and fixed that. Dealt with Millenium bug where 31DEC1999 at 23:59:59 does not roll over to 2000. Created strange number.
Now files have proper dates for 2022.

All this was done in M68000 assembler. The Boot EPROM and the device drivers for booting from the hard and the clock support.

Still doing that kind of stuff eh!

I'm impressed!

You make me remember that my very first exposure to machine language was the intel 4004. I never had a chip though. Just used their books (that they sent you free) to get my feet wet on how it all worked. No internet or email yet.

My first chip was the 8080. Had to be hard coded every time you applied power. No such thing as storage yet. First you programmed some memory with a hex keypad one byte at a time. Then you kicked the processor off. Very painful. Then I got a Rom burner and the whole world changed! Went through a lot of Rom chips though! Every change was a new Rom till I got eprom with a UV Eraser.

All good stuff though. All that knowledge got me onto the team that brought microprocessors to cars. First with testers, and then with the engine. The first engine running on a dyno with a microprocessor doing spark advance was mind blowing. The management were all tube analog guys. Couldn't get their heads around the fact the a processor running off a crystal clock was basically sitting there doing nothing for an eternity till the next spark came along. We tend to think that 6000 rpm is fast. But it's a snail racing an sr71.

Which reminds me - I gotta get an Arduino running on a machine around here.
 

trlvn

Ultra Member
I think you would have liked FORTH. Very much LIKE assembly language. But wasn't.

Personally, I LOVED assembly language. Did more of that than any other. Prolly another reason I liked Octal & Hex too.
Forth did not have to be low level. In the early 1990's, a friend of mine wrote an engineering software package that automated the process of designing roads--as in roads for forestry or mining. It would use topographical information to calculate the amount of fill to be moved to maintain maximum grades and minimum curve radii. It included a 3D visualization of driving of the planned road! All written in MacForth+ and running on 68K Macintosh hardware. My friend was an engineer and taught himself programming. He hated the software that was then available (running on Sun and Apollo workstations). Sadly, though, I've lost track of him.

Craig
 

Susquatch

Ultra Member
Administrator
Moderator
Premium Member
No idea what the last bunch of posts actually said, i'm just a poor uneducated farm boy. All i can say is May the Forth be with you. :p

Almost all the above discussion (from my perspective) is really just reflecting on how lousy BOTH metric and imperial are. They BOTH suck.

All digital devices are binary - all 0s and 1s. A single binary digit can only be a 1 or a 0.

Two digits can be 00 01 10 or 11.

Three binary digits can be 000 001 010 011 100 101 110 or 111 - which is 8 combinations or what I call octal. In decimal equivalent that is 0 1 2 3 4 5 6 or 7. (8 different numbers) Note that there is no 8 or 9

Four binary digits can be 16 combinations which is also called hexa decimal.

But the key point here is that there is no perfect binary multiple for either decimal metric or imperial. They are both stupid concepts that arose from the number of fingers and thumbs or the length of our foot.

If humans had only left their thumbs out of the counting process, we would not have decimal or metric. We would do all our counting and math in octal which would have had a 1 to 1 relationship with digital devices and life would scream instead of grinding to a halt over the need to convert both in our everyday lives as well as in the bowels of computers which had to have software algorithms dedicated to being able to convert back and forth from binary numbers to something humans could relate to.

Ya, I know. Might be better off if I went out to watch my corn grow than fuss over the choices humans made as they came down from the trees...... :rolleyes:
 
Top