I answered this by email by mistake. Assembly has no errors, but binary is not 100% identical to the original.
I believe that that all of the differences are caused by one missing line in your source.pal8, which was dropped for some reason from radar.lst. Search for “0026; 3354; 0000 /;”. Following this should be “0404; 4212; 0200 /<” but it’s missing.
There are also other differences, but they may be due to a bug in the assembler. For example, these two AND (70 generate two literals, but one is 3070!
03010 0375 AND (70 .
03011 3110 DCA X+WR0
03012 1501 TAD I X+WRALST /GET WORD ONE
03013 7510 SPA
03014 5513 JMP I X+WR3
03015 1110 TAD X+WR0
03016 0374 AND (70 /FORM CDF AND PUT IN WR0
The literal section has an extra word inserted, with cascading differences in the code before as a result.
03170 1077
03171 7777
03172 0007
03173 6201
03174 0070
03175 3070
03176 0700
03177 3200
That’s an assembler bug, but it is not present in the source.lst you sent me. Different assemblers? I’m going to run the actual PAL8 under OS/8.
I’ve got more to say about the assembler bug and other assembly issues, but it seems off topic. I think it’s time to split off another topic for discussion that is not about OCR but rather about getting the RADAR code to assemble and, perhaps, run. I think the last two posts by Lars and my posts in reply should go there. I don’t know how to set this up.
I will keep posting here regarding how the character recognition algorithms work. That’s the topic at hand.
New topic split as requested - @larsbrinkhoff hope that works for you. If you need any tweaks which you can’t make, please DM me.
I found the problem. Not an assembler bug. The first TAD (70 at address 3010 has a “.” in column 59 due to an OCR error, confusing a space for a dot due to a little smudge in the scanned image in just the right position. So what the assembler sees is “TAD (70 .”, which means a logical OR of the current PC, 3010, with 0070, which is why the literal is 3070. The binaries are now the same according to OS/8 PAL8. This proves the need to make sure that the binary output agrees with the original 100%.
Note for the record that the code was originally assembled by PAL8 V7, and the OS/8 I have has PAL8 V10D. Probably Lars has the same version. I understand Lars has a Python assembler too. I wonder if there are any known differences.
1 Like
I have been using this: https://www.pdp8online.com/ftp/software/palbart/palbart.c
I have a Python assemblerÂą compatible with a PDP-5 program written in PAL III. But I have been using palbart, so I never updated my assembler.
¹ GitHub - PDP-5/ICBM: DECUS 5-277: ICBM (1970) - game by Len Berger · GitHub
I have one more error. This is from your latest radar.lst from https://retrocomputingforum.com/t/preservation-scanning-and-ocr-tactics-for-old-printouts/5592/23:
This is the original listing:
As you can see, the badly printed 6 at location 5101 has been OCR’ed to 0. For comparison, the other TAD DTUF at 5107 is correct.
Yes, that’s an OCR error. Called it a 0 without warning. I’ve updated radar.lst. The old link now points to the correct version.
I’ve been thinking about what it would take to actually run this code. At a bare minimum a simulator would need to support:
• Index register (this is probably the easy part).
• Priority interrupt system (656x)
• Clock (6370)
• Interval timer (617x)
• Supervisor call (657x)
Note that the priority interrupt system includes the instruction PION=6005. I don’t know what the difference was between PION and DEC standard ION=6001, but it can be safely ignored. We can just define PION=ION.
Nice to have would be
• TTY2 (613x, 614x)
• DECtape
• Storage scope (605x, 606x)
• Some of the HRP hardware (hurricane research project from the Air Force).
• Two-color ASR38, if we decide to simulate radar data.
Then one would need to consider what application code to run. In the complete RADAR system field 1 held radar control and data acquisition and recording, and field 2 held console command interpreter and display generation. None of this has been scanned yet, and it’s larger than what we’ve already done.
It’s not clear that this is the best choice to use with the field 0 system. We could simulate the digital sweep integrator and have it produce fake radar data. Or we could write a simpler set of applications to run under the timesharing system.
Regarding simulator enhancements: I have no interest in modifying SIMH, but I have my own simulator that I’d be willing to update.
This would be an amusing project. Would anyone in the universe besides Lars and me be at all interested in following it, or should it be more of a private affair?
Always worth following a retro adventure! (Might be a new thread though?)
My reason for often (but not always) using and enhancing SIMH is that I like to piggy-back on the existing community and maintenance. It seems to me more likely that SIMH will be usable, say, twenty years from now. As opposed to the all too often case of one-off unmaintained emulators once available on long-dead websites. While good for my personal amusement, I prefer my work on retrocomputing to be useful to others, now and in the future. That said, I’m not against using your emulator provided it builds and runs well on Linux.
I would probably prefer to conduct most of the discussion outside a forum thread, through email or similar.
This is very interesting. And I’d like to read about the progress or at least see the results like a simulator. Can you tell me/us more about your existing simulator? Maybe it helps me with my Festo project. But I understand if detailed discussions will be held elsewhere.
It would be great if there would be a general-purpose, easy-to-use PDP-8 emulator for linux and/or Windows. Maybe with GUI and with modules for different models and peripherals. This is the main problem with those emulators. Maybe with an AI for checking or testing the 6xxx IOTs (like when there’s only a binary and no documented source).
The only good GUI emulator is for MAC.
OCR: Maybe there are more errors. So I think the only way is to manually compare it. The code is not that long. Or at least check the printout for weak parts.