• Please review our updated Terms and Rules here

Programming Altair confusion

I am not sure what you are doing. If you moved everything down by 1 byte in the memory, then that will really screw things up with an 8080!

All of the JMP instructions are absolute - so the next 16-bit jump will cause the CPU to disappear up it's own ALU!

You just can't do things like that when programming and get away with it - unless you have position independent code (as you can write - to a limited extent - with the Z80).

The high pitched noise with the machine ON is what you are listening for.

The 'coloured' program in the link that you published back in post #1 has everything you need to run the program (including the tempo byte (20 hex)).

Dave
 
Last night I changed the listing numbers on the left to reflect what they actually are on the Altair (ie changed 00 to 01, 01 to 02 etc.).

I sense there may be a conceptual skew that happened somewhere up the thread and I worry that you're unintentionally overcomplicating it. I assume you're looking at Dompier's original listing at the bottom of the linked page because we're talking in octal. That listing is already set up to do exactly what you're doing-- entering into the Altair front panel byte by byte-- and uses one line for each single byte of program data to be entered. Multibyte instructions (including ones with 16 bit operands) are already listed in sequential byte order as you're supposed to enter them. For example:

000 LXI H 041
001 b2 xxx - ADDRESS OF FIRST
002 b3 xxx DATA ENTRY

This is listing the values that are meant to go into addresses 0, 1, and 2, in order. (The addresses are written in octal here, in the left column, but of course these numbers look the same as decimal or hex: it's just bytes zero, one, and two; the first three bytes in memory.)

The octal value 041 is an 8-bit value. That value goes into address zero. (It isn't a 16-bit value and doesn't need to be rearranged in any way.) The next two bytes, at 001 and 002, are here shown as "xxx" because he wants you to to just fill in the target address of the LXI instruction yourself. The reason he's making that your job is because he has two songs listed and you might want to switch between them. In Dompier's text, he shows the byte sets for the songs (Fool on the Hill, Daisy) after the program-- he's telling you to put the address of the start of your preferred song data into addresses 001 and 002 (so the program can find it). THIS is where you need to use the little-endian byte swap trick. So if you start entering the music data at address octal 040 for Fool as he notes, then you would input the (octal) 040 into byte address 001 and then zero (octal 000) into byte address 002, because the low byte (040) goes first followed by the higher-order byte (000).

Those three bytes in that sequence represent the full LXI instruction: the opcode and the address operand. Dompier's listing is already made for doing exactly what you're doing-- just walking down the list and depositing each byte into the Altair front panel one byte at a time. He also omits the tempo value at byte address octal 012 as you know, and for that you can enter value 040 (=hex $20) as you've found.

The only time in this whole entering process that you need to consider the 16-bit little endian byte swap is for those two bytes I noted that contain the address (a "pointer") to the start of the music data.

Again, as you continue onwards, it's just one byte for every address:

003 MOV A,M 176
004 CPI 376
005 b2 377 - START OVER DATA

Address 003 needs to contain the single byte value 176. The listing is telling you that this represents a MOV instruction but that's just for your reference here. Then address 004 needs to be set to the single byte value 376 (which represents the first byte of a CPI instruction). Address 005 gets octal value 377, which is the operand for the CPI instruction, but again you don't really need to worry about this, just go byte by byte down the listing.

The process is you reset to address zero, and switch in each byte as you go down the list, and do Deposit-Next or whatever so the address keeps incrementing for you. When you've entered the program you have to enter the music data, which Dompier starts at address 040 matching what you've keyed in above. (Note that there's a gap between the end of the program and the start of the music data here so you'll need to adjust the front panel address after finishing the program before you start entering music data bytes.)

Addendum, but I don't want to confuse further: The listing at the TOP of the linked page is the same program, but redone in hex, and also includes the song data addressed after the program, and all the DIY bytes ("xxx") already filled in. If you're fluent in hex, it might be easier to use this listing, which you could enter entirely by rote. If you'd like to work with Dompier's original octal ("builds character!") you can cross-check yourself on any uncertainties by scrolling up to see if it matches your expectations.
 
Last edited:
Okay so here's where I'm confused. When I start programming, the first address my Altair can deposit to is octal 001. I have done a hard reset, and tried this every way from Sunday. It will not deposit anything at octal 000. I reset, I enter 041 octal for the first byte of data, hit Deposit Next, and that data is shown as deposited at 001 (I assume that's what it means when the A0 light lights up). Likewise the next byte is deposited at 002 (The A1 light lights up), etc.

This is what I was pointing out in my initial post. The comments on the program say you need to put the beginning address of your song in 002 and 003. But if you look at the list, it starts at 000 and the two addresses where you tell the program where to find your music data are 001 and 002. So I wondered if they goofed somewhere, I initially thought the comment was wrong, but now I wondered if the listing numbers themselves were wrong. I thought since it's octal, you start at 0 and go to 7, but my Altair is not starting memory deposits at 000, it starts at 001. So I adjusted the listing to match what the Altair was showing.

So that's really where i'm confused.. is the first address the Altair can deposit data to supposed to be 000 (no address lights lit up)?
 
It might be me.

I just watched another 8800 instructional video, and the presenter resets, then for the first instruction enters his data, then toggles Deposit. For the next byte, he enters the data, then toggles Deposit Next. I think I may have been toggling Deposit Next right off the bat, and it just worked for the example programs in the manual somehow. I'm *fairly* certain I tried it the presenter's way also, but I'm not 100% sure. Going to check it now.

That said, there is something else weird going on - the Protect light illuminates on startup, and it isn't actually protecting memory whether I toggle it on or off. So maybe have some gremlins here.
 
Yes, 0 is a perfectly legitimate address and is needed for an 8080!

Dave
Yes, I should have clued in since octal goes 0 to 7. Put it down to new Altair user confusion - at first I mistook the labelling on the front panel 'A0' to mean I'm at Address Zero when lit by itself, then I compounded the mess by just resetting and using deposit next straight off - I interpreted that switch as 'deposit this here, then go to next address'. Now that I can put out this dumpster fire of novice mistakes, hopefully I can pull this program off. :)
 
That's why the DEPOSIT switch is the way it is--DEPOSIT stuffs data at the currently displayed address; DEPOSIT NEXT increments that address before stuffing. RTFM.
 
Yep,

In the 8800 operator manual it describes hitting RESET to clear the address to $0000.

You then set up your 8 data switches and hit DEPOSIT to store what is on the data switches into memory address $0000.

You then set up your next data byte and hit DEPOSIT-NEXT.

Repeat: data switches and DEPOSIT-NEXT.

You will also notice EXAMINE and EXAMINE-NEXT for the same reason.

As you say, A0 does not indicate Address zero but the A0 bit itself!

>>> Now that I can put out this dumpster fire of novice mistakes, hopefully I can pull this program off.

Let's put it down to too much wine, beer or whatever shall we :)!

Dave
 
Yes! It works! Very static-y but I can definitely hear it now.

I actually read the manual cover to cover, but I am a little.. what's the word.. I don't think dyslexic is correct.. I have some reading comprehension issues. Was a problem in school. I tend to learn by trial and error, and for some reason despite repeatedly reading how the DEPOSIT and DEPOSIT NEXT switches worked, I still managed to jumble them in my brain. But of course when you're learning an unfamiliar machine + unfamiliar numeric system all at once, it can lead to mistakes.

Anyway, very exciting to bear witness to this historic discovery of Steve Dompier's in person! Thank all of you muchly for the assistance. Now to look more closely at the memory protect problems.
 
It must have been really something to see something like thst for the first time (well, on a persona computer anyway) at the HBCC or elsewhere. This is the stuff that really brings the history to life to me, and the history is my main interest with these. I wonder if such a trick were possible on earlier personal computers like the Mark-8.
 
Anything with a CPU could (or should) be able to do it.

They all generate electromagnetic noise of some description...

Dave
 
When I had my Motorola MEK6800D2 (circa 1978), that had a DAC (a ZN452E if I remember correctly) added to a parallel port. That produced quite reasonable music when the output of the DAC was connected to an audio amplifier.

Dave
 
Later I kept getting emails about my conversions not working. Of course, he was forgetting to change bases and units as necessary because he never noted the important things down!

Stupid anecdote: I used to drive a 20 year old Mark I VW Golf GTI (we call them "Rabbits" here.) An amusing bug was the speedometer was way off, reading about 25% too high. (All the thrills of speeding without the legal exposure, I guess.) One day on a freeway, speed limit 65, with the speedometer pegged at 80 it crossed my mind that the meter was perfectly accurate if I simply assumed it was calibrated in octal. Obviously it was a joke... but nonetheless, for as long as I owned that car I was extremely proficient at rapidly converting between decimal and octal in my head.
 
Anything with a CPU could (or should) be able to do it.

They all generate electromagnetic noise of some description...

For those of us insufficiently rich of blood to own an Altair or Mark-8 I would assume the same program would work on a TRS-80 Model I. Probably better, actually, given the plastic case.
 
Back
Top