Front Panel activities

[Bluman]

This post is more of a self-introduction and a catalog of things I'd like to try once my Altair Clone arrives. I've built and owned a number of Z80 systems and enjoy my nostalgia time with CP/M and BASIC and so the main attraction to the clone is the blinkenlights and front panel programming. I saw a number of posts asking for front panel activities beyond the listings on the Altair Clone support page and thought I'd post whatever I happen to try.
My plan for this new toy is to try and entertain myself for at least two weeks without plugging into a serial terminal. (Accessing the settings menu being an exception.) Day one will probably be playing with Kill the Bits and Pong and switching in whatever listings I happen to find. After that I'll post the programs I write to this thread.
The thought process is basically pretend like I could afford the base kit and that's all I've got for a while.

My initial planned activities are:

• Insertion Sort
  Quick Sort
  Multiplication/Division
  16-bit & 32-bit integers
  Floating Point Routines
  Cassette Saving/Loading Programs & Raw Data

Maybe I'll include building a serial hex keypad in that list for data entry.
Also, once I find my books on 8080 and Z80 assembly and some of the "build your own computer" type books, I'll add in anything interesting there that I can find.
If anybody has ideas for anything else to try, feel free to chime in.

[TronDD]

That's cool! I did the same thing. Started coding on paper, hand assembling, and doing IO entirely with the switches and lights. I made XOR-shift PseudoRNG and a count down timer using the RTC.

Didn't take me long to add a serial console and, a few programs on paper later, move to using a text editor. :D

[Wayne Parham]

That's pretty cool, I get it.

The front-panel is useful for that, of course, and I always personally preferred computers with front-panels to those with a soft-console. It's nice to be able to access the system without any built-in programming at all, e.g. bootstrap or monitor ROM. So it's cool to have a front-panel as a primitive user-interface.

But to be honest, the reason I always liked systems with front-panels wasn't really the user-interface, but more as a visual activity meter. You can kind of tell the sorts of things the system is doing just by looking at the front panel. In addition to knowing that the system is active versus idle, you get a "feel" for what it's doing by the binary progressions and the pattern of the "blur."

Here's an interesting aside, sort of a stroll down memory lane: I remember a popular process called "the Cylon patch" on Data General minicomputers running their AOS operating system. It made the front panel lights run a single bit back and forth across the front-panel. At idle, the speed of the progression was pretty rapid, with the light moving from left to right in about a half second. So it would go fully back and forth once a second or so. But as users loaded the system and it became more active, the speed of the side-to-side movement would slow down. That was kind of cool.

Usually though, most systems just display their address and data buss contents as things "fly by." And I like that best. I like seeing the pattern in the blur.

[Bluman]

But to be honest, the reason I always liked systems with front-panels wasn't really the user-interface, but more as a visual activity meter. You can kind of tell the sorts of things the system is doing just by looking at the front panel. In addition to knowing that the system is active versus idle, you get a "feel" for what it's doing by the binary progressions and the pattern of the "blur."

I can see that. I assembled and played with the PiDP-11/70 and PiDP-8I kits and it was fun trying to associate light patterns to certain software activities but I never had any real world experience with any of the minicomputers and that limited the fun with them. Maybe I should build a bus activity light board for my RC2014. (Though an Altair-style front panel has been on the backburner for a couple years now...)

BTW, the Altair Clone showed up the other night. I haven't gotten to play with it much yet but it's a beautiful, well built, well packed, professional piece of kit.

I'm hoping to start dumping code listings in here over the weekend but here's an attempt at zeroing out memory:

Code: Select all

1000 041		LXI HL,0
1001 000
1002 000
1003 066 S	MOVI M,0
1004 000
1005 043		LXI HL
1006 076		MOV A,2
1007 002
1010 274		CMP H
1011 302		JNZ S
1012 003
1013 002
1014 166		HLT

I put this in at octal 1000 and then again at 0 to clear out the first 1k in two steps. I'm still getting a feel for things and NOPs help me recognize the end of my program. This way I'm not trying figure out if garbage memory is meant to be part of my listing and I'm off a line in my notebook or if I've actually got things right for once.

Since the game is to play with a minimal system and also relive the "I got this computer-thing but what do I even do with it" scenario, whenever I finally hook it in to a terminal, I'll try setting the top 63k to ROM to enforce playing w/ a 1k system. If I read the manual right, I should be able to set a start and a length for a ROM and I guess just zero it all out. Though, if the bus floats, should it all just be random?

[TronDD]

The 1975 01 04 issue of Computer Notes has a memory clearing program:

The ultimate in memory clears seems to have been written by Ward Christensen (#731751).
"I have been using the follow-ing 'program' to clear memory in my Altair since the first week I had it. It clears all of memory except byte 0, and leaves the address in location 1. It works because the Altair seems to have the stack pointer at location 0 when powered up. At worst, it would have to be run twice."
0000 063 INX SP
0001 307 RST 0

[Bluman]

The 1975 01 04 issue of Computer Notes has a memory clearing program:

The ultimate in memory clears seems to have been written by Ward Christensen (#731751).
"I have been using the follow-ing 'program' to clear memory in my Altair since the first week I had it. It clears all of memory except byte 0, and leaves the address in location 1. It works because the Altair seems to have the stack pointer at location 0 when powered up. At worst, it would have to be run twice."
0000 063 INX SP
0001 307 RST 0

Nice! Thanks. I miss creative programming like that even though 'creative' is a bit of a swear in my software development world. :)
If I reset and run as-is, I get alternating 0s and 2s though memory. If I single step over the INX SP once, examine 0, and then run, I can get zeroes until both instructions get smashed. Maybe that's the "run twice".

I got a couple hours in with the clone over the weekend but got completely squirreled with passing arguments on the stack. (Also, the holiday meant reduced hobby hours.) I spend my day job glued to current high level languages but I'm still embarrassed how rusty I am at assembly.
I found this in the BDS C source and I just felt I should have seen something similar a lot earlier. (ma0toh through ma7toh labels in CCC.ASM)

Code: Select all

LXI H,<n>
DAD SP
MOV A,M
INX H
MOV H,M
MOV L,A
RET

So far I don't have a need to pass args on the stack but maybe it's a comfort zone thing. No real reason as to why but I couldn't rest until I figured it out. Now that I see a way that it's
I guess LXI H,0 followed by DAD SP is the way to get the current SP w/o changing it.
Otherwise I managed to write a routine that copies memory from one location to another. IIRC it's a single Z80 instruction but took me nearly a dozen on 8080. (I misplaced my notebook, otw I'd post a listing.)

I really thought I'd have gotten more done by now. I just have to keep at it. I've gotten nothing on my initial list done..... but bright side is that this means that I'm having more fun with the Altair Clone than anticipated.