Blog

France: Grand Seine River & Normandy Passage Cruise

We just returned from France! We booked a cruise based on a mailing from the Wisconisin (the *real* UW) Alumni Association late in 2024. The cruise took place in October, 2025. We had a great time!

Overview

The cruise was organized and managed by AHI Travel (AHI), an organization operating out of Illinois, in coordination with the Wisconsin Alumni Association (WAA). Our trip started with a two day “pre trip” in Paris, followed by a 9 day excursion on the MS Renoir on the river Seine, oerated by CroisiEurope Cruises.

On the whole, the experience was delightful, with many great memories, detailed below.

The Cruise Staff

We had three “Travel Directors” on our ship, employed by AHI: Fred Burke, Reinhard (Rainer) Groeting and Signy Brink (more info on each is available on the AHI website). They were all wonderful and helpful during the trip, and were very understanding and helpful in tailoring the experience to accommodate my Gail’s currently limited mobility.

In addition, the WAA sent Melissa Zehner along on the trip, and she was also a great resource to have along on the trip.

More on the ship’s crew later.

A Shout-out to TSA

Yup – a positive report on our experience with travel security during the trip. When we went through security in Madison (TSA Pre-check), they discovered that this idiot (i.e., myself) had managed to leave a Swiss army knife in his briefcase. When they took my briefcase over for a more thorough search, that was not a big surprise – it had all my electronics, chargers, Lithium batteries, etc. inside. But the agent poked and prodded for quite a while, at one point asking if there was anything that I knew of that was sharp inside. I indicated that no, not to my knowledge, but after a bit more searching, produced my knife — with my name on it. OOOPS!!! It had been a gift from my wife a few years back, and I had moved it from my backpack to that case who knows when, and didn’t notice it, even when I first emptied that case and probed it myself before I started packing it up. The agent was very good about it, offered that I could go back, have the airline retrieve my checked bag (I declined) and then kindly confiscated the thing. No hassle, no barking, just doing his job to protect us all. Thanks, buddy.

And then, in Detroit, going throu security after our return flight from France, I noticed at the last minute I had not taken my FitBit and Apple Watch off and put them in my briefcase, as I usually do. So I then removed them and tossed them in the bin with my briefcase. But after I went through the metal detector and retrieved my briefcase, neither was in the bin — though my FitBit was in the briefcase side fold at that point (perhaps put there, perhaps by random chance). No Apple watch. I searched in a panic, but came up empty. At that point I decided to look for a TSA agent, but he was not at his desk at the end of the security check at that point. I waited, and looked again and there he was, holding my watch. I came up, pointed to it and said it was mine, and he returned it to me no questions asked. I unlocked it, and mentioned I had done so, demonstrating that it was mine. Again, no muss, no fuss.

And these guys are not currently even receiving their paychecks!

Days 1 and 2: Getting to Paris

We purchased the “Paris pre-trip extension”, and arrived in Paris one calendar day after we left, because of the long flight and a 7 hour time difference.

(Unfortunately, a couple of days before our scheduled departure, our 10 year-old washing machine broke down – so I had to do the laundry at a nearby laundromat!)

Dealing with Charles de Gaulle (CDG) airport was hard for Gail. First off, when we arrived, I had not noticed that we arrived in Terminal 2, sub-terminal M instead of the expected sub-terminal K, so got a little confused looking for immigration/border control. We ended up in the basement of “M”, and asked airport staff how to get to border control, and while they were very pleasant, they didn’t seem to know either!! A few departing travelers incorrectly suggested that we must have already gone through immegration to get there. Finally someone pointed us in the right direction, and after going up some stairs and/or elevators, reached the automated shuttle train stop. I was quite confused, because I though we were already in “K” when in fact we where in “M”, but at the last instant decided to hop on the train, and just as I did that, the door started to close on my backpack. I got on, but Gail didn’t. I shouted I would get off on the next stop (which is “L”) and did so. When the train arrived, I didn’t see Gail at first, but then spotted her, and hopped on to her train car. We then proceeded to “K” and got off.

MORE stairs / elevators and we finally got to immigration, aka border control. There we caught a break, and an attendant spotted Gail’s cane, and directed us to the priority line used by flight crews and the like. Five minutes and we were through – along with an unexpected entry stamp on the visa page of our passports – didn’t know folks ever did that anymore.

Then it was off to pick up our bags. Not spying an elevator, Gail managed like a trooper and took the stairs. Our bags were already on the carousel waiting for us. Picked them up and headed off to find customs.

On the way to customs I intended to exchange a smallish amount of dollars for euros, planning to use ATMs to get euros for later substantial gratuities for the travel directors and ship’s crew, but I foolishly let the attendant talk me into exchanging more. Ouch. Dumb.

Customs was a non-issue. There were guards there, but nobody asked any questions of anyone — and we had nothing to declare, anyway.

Next, it was off to find the AHI sponsored transfer to Paris. After customs I looked for them, but didn’t see their sign at first, so I parked our luggage with Gail, and went back and looked and found them. The staffer loaded our stuff onto the bus and off we went. It was a circuitous route from Terminal 2 to Terminal 1 to pick up some more fellow travellers – but there were only about five of us on a full size bus to get to the hotel.

L’Hotel Hilton Paris Opera

Nice hotel. Very nice indeed, with lobby decor appropriate to Paris – but otherwise quite American. The day we arrived, the revolving doors were not working, so the lobby staff / porters (and there were several) pushed to door to help guests. We had two full sized beds, side by side.

Our rooms were not yet ready, so we decided to go get some lunch. Signy suggested we try out Brasseries Mollard, across the street.

Breakfasts were a very good buffet, with a variety of foods available, including some pretty good pastries. They were included with our room.

Brasserie Mollard

A “real deal” of a French restaurant. (You can see a reflection of Gail and me as she took the photo immediately above!) We arrived about 15 minutes before they started serving (which was good, but confusing for them and us), and requsted “une table pour deux” – forgetting that restaurants don’t typically open for “dejeuner” until noon. The maitre d’ was a little upset, and didn’t speak English, but finally got his point across by pointing to his watch saying (pretty loudly) “a midi” (at noon), to which I responded “je comprends” and we had a seat. Shortly a nice hostess confirmed that we were OK to wait and would be able to get a table.

When it was time, very shortly after noon, we did get a table, but it was clearly not a great location – it was a long-ish table, with a power cord for the lamp running diagonally over one corner.

At first the waiter didn’t seem to understand my request for “une carafe d’eau” and served me a bottle of water (which is not free), but later did bring the carafe over for us. The waiters were not snooty at all, and served us nicely. Speaking a little French certainly helps!

Gail had some salmon, and I had some chicken. Both were delicious.

At the end of the meal, we had desserts. Delicious!

After our delicious lunch, it was back to the hotel – but our rooms were not yet ready. After a couple of checks every 15 minutes or so, I nodded off in a nice wing-back lobby chair. Signy came over and touched me gently on the shoulder to wake me, and then helped expedite the process of getting our room.

After lunch, and getting into our room, we crashed until a small reception for tour guests held by AHI in one of the hotel’s reception rooms. Afterwards, we decided to eat small, and went across the street to Brioche Doree, across the street from our hotel, which turns out to be a world-wide chain. They were nearly out for the day, but we had a turkey sandwich and a tuna salad sandwitch along with some chocolate eclairs. Pretty darned good for fast food from a tiny hole-in-the-wall. In the process, I discovered that one of my credit cards (the only one I had with me from the hotel across the street) wasn’t set up properly for France, and had to quick run back to get my other card to come back and pay. The restaurant was actually willing to let us have the food and come back later to pay.

Day 3 – Paris

After breakfast, the trip included a guided bus tour of Paris, hitting the expected spots along the way. Not so great for photos, unfortunately.

Then off to a guided walking tour of Le Marais district (literally, the marsh – as it was built on one). Gail and I parted company at the BHV department store. She and her newfound friend Tommie stayed behind and did some shopping, and then waited for us in a nearby cafe.

First stop was l’eglise Saint-Gervais-Saint-Protais – very beautiful, indeed:

The tour also visited some monuments dedicated to the Jewish community that suffered greatly during WW II:

Also scattered about Le Marais were some 8-bit-ish pixelated images, apparently designed by an artist known as “Invader“. These can be found all over the world.

At the end of the walking tour, Gail and her buddy rejoined us, and we went back to the hotel, and had lunch at “Hippopotamus”, again, across the street from our hotel – which turns out to be a chain of grill restaurants.

After lunch it was off to Notre-Dame. Getting the taxi was a little weird. The first two taxis and some customers appeared to have some small disagreement, and when we went to the third, he declined pointing ahead in the line. After a bit we came back, and by then he had realized that he was actually the front of the usable line, and we climbed in. The driver seemed concerned that we would understand that he had to go around the block at the beginning – I think he saw me looking at the meter – but I was not concerned at all. A short trip in traffic, and a standard faire of a bit under 30 euros, and we arrived at our destination: Notre-Dame de Paris.

Being more of less off-season (though a vacation time for children), the line was short and moved quickly — but when the staff saw my Gail’s cane, they directed us to the no-line timed entry station, and we went in. We took some beautiful photos, and then attended Vespers. Very nice. As you can see from the first photo some restoration work is still in progress.

After Notre-Dame we were pretty hungry, so we grabbed some food at a little Italian place on a street near by, Cafe Leone. Just the ticket.

After that, it was time to find our way back, which turned into a silly adventure. It did not occur to me to open a map app to get to a taxi stand, we we took a wrong turn on the street. Finally we gave up and I flagged down a tax just coming off L’Ile de la Cite and we jumped in just around the corner. The driver didn’t speak any English, but I managed to communicate the name of our hotel, and a standard fare later, we arrived back and ready for bed. While she was waiting at the corner, Gail took this photo across the Seine back towards L’Ile de la Cite (you can make out a bit of Notre Dame in the background.

Day 4 – Embarkation Day and Paris By Night Sail

No time for touring, we had breakfast, and then packed back up and notified the porters our bags were ready, before checking out.

We had a very pleasant lunch at Cafe Marco Polo, once again, just across the street.

Then it was back to the hotel lobby to get our transfer over to the MS Renoir.

During dinner, the ship left the dock and sailed to the South and East – the opposite of our eventual direction, so that we could sail through Paris that evening. The bridges in Paris can be very low, and this ship is specially equipped so that the wheelhouse and the canopy for the passenger area above decks can actually be lowered down to deck level. The top photo shows the wheelhouse in its raised position. The photo of the Statue of Liberty in Paris below is quite fuzzy as light was low and the boat was, of course, moving…

We said “au revoir” to Paris as the ship sailed on to Poissy.

Day 5 – The Palace of Versailles

A first trip to France would presumably be incomplete without the obligatory visit to the palace of Versailles. But what a madhouse — and we were there “off season”. They used a timed-entry setup for groups, and we tood a long time waiting for our time (and then some), which was a bit difficult for Gail.

It was very crowded, so getting good photos taken was sometimes hard – we eventually decided to just go buy the book at the end (all tours end at the gift shop, after all.)

The rest of the day was spent under way, making our way to Rouen, navigating through some locks along the way.

Day 6 – Rouen and Normandy Abbeys

The day started with a walking tour of Rouen. We spent most of our time at the Rouen Cathedral – whose central spire is undergoing some renovation. Rouen is also notable because that is where Joan of Arc met her untimely death. The image below, after the statue, tells the tale in imagery.

In the afternoon we took a bus to two abbeys in Normandy. The first one was Jumieges Abbey, and is in ruins, having been destroyed during the French Revolution. That day they were having a Halloween celebration of sorts.

After Jumiges Abbey, we took the bus to Saint-Wandrille Abbey – which is still in operation. Restoration is being done on a continuous basis, from contributions (like I made) and also from sales at the gift shop — encouraged by the delightful monk who guided us on our tour through the abbey.

After returning to the ship, we continued on, sailing to Honfleur.

Day 7 – Honfleur and the cliffs of Etretat.

After sailing under the Pont de Normandie between Honfleur and Le Havre early in the morning, the next day’s excursions begain with a trip to Etretat, a delightful little town North of Le Havre. There we also visited the cliffs, consisting of limestone and darker flint, by way of a little open-air “train” of sorts.

While I was wandering around Etretat, Gail and our new acquaintences Sam and Karen had some coffee at a cafe.

After lunch, we took a tour of the Eugene Boudin Museum. Boudin is said to have mentored and inspired Claude Monet in his work. I took lots of pictures of realistic paintings of ships and seascapes. We also saw a room-sized game of snakes and ladders.

After the museum, Gail and I opted out of most of the walking tour of Honfleur, and visited a touristy gift shop and bought some funny placemates, and the Cacaotier chocolate shop.

Day 8 – The WW II Beaches of Normandy

The beaches of Operation Overlord are legendary, of course, and with good reason. Such sacrifice! Our guide for the day was Marie – and a very wonderful guide she was – a Francophone for sure – but with a British accent to her English. She had all the facts and figures and stories one could want — all memorized, along with maps she could pull out when needed.

First we visited Pointe de Hoc, where U.S. Rangers scaled the cliffs, assigned to take out German artillery emplacements. However, it turned out that those guns, originally out in the open with no protection, had been moved, and telephone poles were in their place as decoy, and there were only German engineering troops there, buiding what they hoped would be protective bunkers for the guns when they returned (first photo, below). There was also a command post there (second photo), with bomb craters all over the place. Good thing there were fences to guide tourists!

The next stop was Omaha beach, where so many of the American troops perished, and where I knelt down in the sand to pay my respects. (At the time of the invasion, the beach was not sand, but was instead pebbles, which caused any mis-aimed German fire to turn into shrapnel, multiplying the misery faced by the Americans. Thus, a lot of the monuments have pebbles surrounding them or inside their confines.) Below are the main monument and “Les Braves” sculpture.

The last stop before lunch was Colleville-sur-Mer, the site of the Normandy American Military Cemetary, with its graves counting more than 9800, all aligned with great precision.

Then lunch – at a country club. (Yup, they golf in Normandy, in the rain.)

Following lunch, we paid a visit to the Caen Peace Memorial WW II museum.

Wow. What a day. On the way back I had a nice chat with tour director Rainer – but also felt my throat getting sore — as I was getting a cold (but fortunately *not* COVID).

Day 9 – Claude Monet’s Home and Gardens

This was the last day we were really active on our trip (see Day 10) – a visit to Claude Monet’s home and gardens. We didn’t go into the home, but we explored the gardens thoroughly. Thanks to assistance from Fred and Rainer, we stayed behind the main group, but got early entry into the garden’s themselves.

Later that afternoon, I had a chance to visit the ship’s wheelhouse.

That evening’s event was the Gala dinner. It was held a day early because the next night was the night before we had to pack up and leave – with our bags to be ready at 5 AM. Dessert was baked Alaska, no less.

Day 10 – Back to Paris

Overnight the ship returned to Paris, to the same dock where we had joined the ship. The weather was windy and potentially rainy, and as we had already taken a bus tour of Paris, had sailed thru Paris at night, visited Notre Dame, and had walked around a couple of areas, we opted out of the river tour and walking tour of the Latin Quarter.

But I still had one item on my Paris “bucket list” — to visit une patisserie! Fortunately there was one just a few blocks from the dock — La Duchesse. Yum!

Day 11 – Back to Madison

Waking up at 4AM, it was time to pack our bags before 5AM, and grab “un croissant” and some of the pastry I bought the day before, before boarding the bus at 5:30 for L’Aeorport Charles de Gaulle (CDG). The traffic was light, but the bus dopped us off at terminal 2F (we were told that was the closest it could get to terminal 2E), which meant a long walk to our terminal, which was tough for Gail. The AHI person handling our bags suggested we ask for mobility assistance, which we did.

The person assigned to Gail was a perhaps 30-something young woman, who as very nice, but spoke no English. She often asked how Gail and I (I was walking, carrying our carry on items) were doing (“Ca va?”) and took great care of us. We were escorted through border control and security. Just as we got to emmigration, the person in the booth we expected to visit went on break, and I could see that our escort was puzzled and annoyed by that some. After border control we then took a rather circuitous route down to the lowest level near a door to the tarmac. We were shuffled from chair to chair – it was a little disconcerting because we didn’t know how we were going to get from terminal 2K, where we were, to 2M. Our escort finally resorted to Google translate (or some such) to let us know a bus (a van, actually) would pick us up. The van then dropped us off at terminal 2E M – where our gate was. We chose to walk to the gate as we had plenty of time. Fortunately, just before bording our escort reappeared with another customer, and I was able to slip her a small tip, for which she seemed greatful.

The service was very nice but the initial wait for our escort was more than 15 minutes, as was the wait for the van, so our whole experience was nearly two hours, whereas when we arrived and navigated through things ourselves we got through in maybe 75 minutes.

The flight home was uneventful. Getting through Detroit DTW involved some walking which was a little tough for Gail, but straight-forward. The immigration officer seemed to be doing double duty as customs, as he also asked what we had returned with (and I also had used the handy MPC app to make our declarations). Retriving my Apple watch from the TSA agent (see above), we then snagged our luggage off the carousel and took it to the special connecting flight check in spot – a nice arrangement. We were a little concerned because the bar code on Gail’s bag had been completely mangled, folding over itself, but both of our bags made it onto the plane and showed up in Madison.

In Memoriam: Professor Richard Marleau

I learned today that Professor Marleau passed away in 2021. I took a couple of courses from him. If I remember correctly, the first was ECE 331 State Space Systems Analysis. It was hard. Then, the next summer, in 1972, I did an independent study course with him working on very rudimentary computer graphics software. (Mostly, it was so slow that it made a really good case for the need for a separate graphics processor, the VT11 and the GT40 system.)

Many years later, while I and Hannes Beinert were acquiring computers for my collection, I learned through UW Surplus that Professor Marleau was decommissioning a large amount of DEC PDP-11 minicomputer equipment to make way for a new generation of equipment based on Unix workstations. He graciously arranged, through UW Surplus, for the entire set of equipment, manuals, tapes and disks to come into my possession, where the equipment still remains. Recently, I started the process of scanning in the documentation, and making it available on my Google drive and hopefully, should they see fit, on the bitsavers.org website.

More information on Professor Marleau can be found at the ECE Emeritus page in his honor (which also includes a link to his obituary.)

Professor Emeritus Richard Marleau passes away

IBM 1410 FPGA: Overlapped I/O Fix

Overlapped Tape I/O is generally working OK now. Getting that to work involved two things.

Firstly, I needed a delay corresponding to the tape inter-record gap time (though not nearly that long) so that the several instructions that the diagnostic runs through before it tests for an overlapped condition would occur while an I/O Overlap still in progress. This fixed the error stop problem. Fortunately, that was much easier to find and fix than I had expected.

After fixing that problem, overlapped reads worked correctly, but overlapped writes had a problem – they somtimes dddduplicated characters 😉 – resulting in records longer than they should have been (and with incorrect contents).

The latter turned out to be more or less self inflicted. In August of 2023, I encountered some issues with the Store A Address Register (SAR) instruction. To fix that I used the +S ADDR MOD SET TO ZERO signal to inhibit resetting the modify by zero address modifier control latch, reasoning that latches don’t respond well to having simultaneous set and reset signals active at the same time.

The post relating to that change is available at:

https://www.computercollection.net/index.php/2023/08/03/ibm-1410-fpga-smore-sar-instruction-issues/

In this case, however, that was causing the Modify by Zero Address Latch to not reset at times when it needed to, which then sometimes inhibited the Modify by +1 Address Latch from setting, causing the address for the I/O to not increment properly.

The fix was to modify the ALD that generates the address modificatio signals, ALD 14.71.41.1 ADDRESS MODIFIER CONTROLS to inhibit generation of the +S ADDR MOD SET TO ZERO signal in the presence of +S ADDR MOD SET TO PLUS ONE. For now, that was done directly in the VHDL. To fix it in the ALD I would need to add a couple of “phantom” gates.

The wrong length record issues when writing for locations ending at the end of memory remain, as does Error 17 involving the timing of longer inter-record gaps expected from a tape Erase call, and some other errors involving the 2nd channel (tape marks? backspaces?) still remain.

IBM 1410 FPGA: Wrong Wrong Length Record

The vast majority of errors noted by the tape diagnostic T020C related to wrong length record errors, particularly when a tape operation writes from the last character of storage (39999 in my current 40K implementation), usually starting at location 39990.

The current FPGA from the ALDs implementation does not create an error stop, it simply writes until it has written the character at location 39998 and stops, with a wrong length record (WLR) error – with one less character written than the diagnostic would expect, as well. (Then, subsequently, the read operations in the tests also generate WLR because they are expecting 10 characters, but only get 9).

Part of the problem is that various documents describe what should happen in such a case differently:

Diagnostic T020C (1964):

  • The diagnostics do not expect an WLR when writing from the last location in core storage or reading into the last location in core storage. (A WLR would presumably occur when reading into the last location of core storage if the record extends beyond that character.)

A22-0526 (no suffix) 1963

  • Addressing: During execution of an instruction, no address must be decremented past 00000 or incremented past the highest valid address. This includes operations that act on data in a single position only; such operations will be executed but, after the operation the associated address register will contain an address beyond one of the limits and the system will stop and signal an error.
  • Tape: WLR is never set on a Write or Unit control operation, unless the record is of zero length, i.e. the character at the start is a Group Mark with a Word Mark.
  • Tape: Read to End of Core ($): Reads until the last storage position is filled.
  • Tape: Write to End of Core (X): Writes until the last storage position is encountered. [ed: to me this is a little vague: does it mean that the last character storage position is written from, or not?]
  • Console I/O: WLR is never set (I have not yet tested this)

A22-0526-3 (1961) and A22-0526-2

  • Addressing: If an operation increments addresses, 59998 is the highest position (assuming a 60K system) that can be referenced or in which data can be read or inserted as the result of an instruction. If 59999 is addressed in an incrementing operation, the system will stop and signal an address check. There are two exceptions: 1. A manual console operation; that is display and alter. 2. Data may be read from or inserted into 59999 without causing an address check in the execution of a read or write “to end of core” I/O instruction.
  • Tape: WLR (W-U) Never set (unless record is of zero length and first character written is GM/WM)
  • Tape: Read to End of Core ($) and Write to End of Core (X): read/written until the last core-storage position is encountered. (Notice that this older document does not specifically differentiate between the read and write behaviors)

The ALDs for my machine in these areas are all dated 1962.

Because this issue is unlikely to cause operational issues, I expect to “table” it for now and revisit it later. It may be that ECOs were required to change the behavior to what is expected in the diagnostic.

UPDATE: This turned out to be very easy to fix. At first I tried all sorts of things to try and control the setting of the Internal End of Transfer Latch by inhibiting setting that when the channel Wrap Condition was asserted — but that led to an address check as the 1411 CPU tried to fetch the next higher location, instead of wrapping around to location 0.

So then I decided that I would just make a change to the ALDs on pages 13.71.05.1 (E Channel) and 13.66.09.1 (F Channel) to suppress the MC_DISCONNECT_CALL to the TAU while the E2/F2 register was still full. That worked — even better than I expected. Not only did that cause it to write out the last location of memory, it also caused the Wrong Length Record status to go away as well.

That left me with ONLY ERROR 17 on the E channel. The F Channel had ERROR 17, but also errors 20, 23 and 70, which seemed odd. But otherwise, both channels read and write tape just fine.

Error 20 occurs when a tape mark is read, and the diagnostic expects that the CPU will also set the CONDITION status for the I/O operation, but it was not setting the CONDITION status.

IBM 1410 FPGA: From USB Serial to UDP over Ethernet

Seeing that some of the problems that I had identified with the Tape Adapter Unit (TAU) implementation could be or might be traceable back to the fact that I was using a 115,200 bps serial over USB to communicate between the 1410 FPGA implementation and the PC side support program, I decided to look at alternatives.

  • I2C would be too slow, and I would need some kind of intermediary like a PIC or Raspberry PI to talk I2C and then something else, like TCP/IP or UDP to talk to the PC side.
  • SPI, at 10Mbps would probably be fast enough, but also would need an intermediary.
  • I could use an embedded soft processor, like a MicroBlaze, on the FPGA. That would probably work, but would take up a lot of resources on the FPGA, and I was concerned that the Xilinx XC7A100T might not have enough for all of the things I might want to do, especially with a TCP or UDP stack added in. I did do a little playing with Microblaze a few years back, and found the development process somewhat cumbersome: it would considerably lengthen all of the place and route everytime I made a change.
  • Understandably there do not seem to be any direct TCP implementations in VHDL or Verilog that I could find.
  • I found three different implementations of UDP, two in VHDL and one in Verilog that I decided to test.

Two of the UDP implementations were on opencores.org. They were old, apparently done as a research project, and it was not apparent how to configure it to work on my hardware, so I quickly abandoned those. Plus, it took opencores.org three months to grant my request for a user ID.

Next I looked at the UDP implementation from Alex Forencich. At the time, it was located at https://github.com/alexforencich/verilog-ethernet, however, that one has apparently been superceded by one at https://github.com/fpganinja/taxi — however this latter one seems to no longer include a UDP stack. This UDP implementation looked promising, however there were a couple of issues for me. Firstly, it used a generation process using cocotb. When I tried to do that, it did not work well for me. So, I ended up doing what it would have done to figure out what files I actually needed.

The second issue with this UDP implementation from Alex Forencich was that it was not directly complatible with the physical ethernet interface (PHY) on my Nexys4 development board. It is set up to interface with an MII layer, however, my Nexys4 PHY uses an RMII layer. I tried a couple of approaches to resolve this issue. The first was to see if the Ethernet MAC at https://github.com/chasep255/Nexys-4-DDR-Ethernet-Mac would work. It provides an AXI interface to the Ethernet MAC on the Nexys4 board, but also uses RMII. There was something important I cleaned from this latter project however: how to build a test bench to send and receive Ethernet packets, which I used quite a bit.

In the end I found a free MII to RMII v2.0 interface layer IP from Xilinx. While not available in the latest versions of Vivado, it was still there in my older versions of Vivado, and while not supported by Xilinx, it works fine in Vivado 2023.1, and I would expect it will continue to function OK in later releases as well. And, worst case I could also do a development board upgrade to something that has an Ethernet interface using MII.

It took me quite a bit of futzing around to get Alex Forencich’s UDP layer working as it was in Verilog, and I need to interface to it with VHDL. Also, the example/sample logic just does a UDP echo, and it took some time and testing to figure out how to separate out sending and receiving UDP packets.

Once I had it working, it was not tremendously difficult to integrate it into my 1410 FPGA logic. I chose to continue to use a stream UART-like interface that is as close as possible to what I had for an actual UART, so that only minimal changes were required in my existing state machines. I did need to expand the intermediary output related FIFOs from 8 bits to 9 in the logic, however, to carry a “flush flag” so that, for example, when the 1410 needed to send a UDP request for a tape operation, it could force the UDP layer to send the packet even though it was not full. Everything else remained essentially the same as when I was using a serial port.

I now use the UDP implementation for TAU related packets going both ways, to and from the FPGA, for lamp data going from the FPGA to the PC and for sending memory images (“core loads”) from the PC to the FPGA. I did find that I have to throttle the lamps some and not update them as fast as I’d like – the speed of the C# code and Windows updates are a limiting factor. I even found that on tape writes I had to add what kind of corresponds to a tape stop in the inter-record gap, to add a delay when writing so that it does not overwhelm the PC (which leads to lost packet(s) and a program error). I also added some delay when the PC is sending data back to the FPGA for tape reads so that it does not overwhelm the FPGA UDP stack.

With those changes, it can now reliable write and read tape records, though some tape related problems when running diagnostic T020 remain unchanged:

  • Error 17, caused by a test of the ability to do an erase operation to write a long interrecord gap over a bad stretch of tape.
  • Errors 39, 41 and tape I/O operations resulting in Wrong Length Record Status. The problem relates to what happens when writing a record that goes to the end of core storage (with no Group Mark + Word Mark) and reading records that go to the end of core storage.
  • In one of the later tests a read tape to end of core is executed, in odd parity. The tape data is in odd parity as well. However, the operation generates a data check, and core storage from 39990 to 39998 (for a 9 character record) are all asterisks from what the 1410 sees as an invalid parity.
  • On Channel 2 / F Channel, errors 20, 23 and 70 which seem to relate to problems when a tape mark is encountered after writing one and backspacing over it.
  • T020 starts by trying an overlapped write on each tape drive. If it finds one that is ready, the result is a 1410 error stop, I think on an “R” I/O status branch instruction, with only 1 byte transferred to the PC.

IBM 1410 FPGA: TAU Not So Fast

In May of 2024, I turned my attention to Tape I/O. On a real IBM 1410, this I/O would be routed through an IBM 1414 I/O Synchronizer (Model 1, 2 or 7, also known as Tape Adapter Units (TAUs). However, there were two issues with that for me. Firstly, I do not have ALDs for the TAU. Secondly, because the TAU expects to interface with a real tape drive, and I don’t have any, the timing would not work. Fortunately I soon discovered that the IBM 1410 channels don’t actually care about the timing – they are driven by the MC_TAPE_READ_STROBE and MC_TAPE_WRITE_STROBE signals from the TAU.

It took me from mid May 2024 to mid July 2024 to design the logic, test, and work out bugs to the point where I could load diagnostics from the diagnostic tape and they would run. This was a significant milesone!

Testing revealed several problems when running the first tape diagnostic, TU20:

  • Error 17. This error happens because my setup ignores erase requests which write long inter record gaps (IRGs), and the diagnostic expects to see different times (measured in a timing loop) when reading a record with a normal IRG vs. one after an erase with a long IRG. This is not a “real problem”.
  • Many errors displayed for reads and writes which involve the end of memory. The writes write records only through location 39998 before an internal and of transfer stops the transfer, and then the reads aren’t as long as expected, either.
  • Errors 39 and 41, which involve writes which try to read one character past the end of memory.
  • Problems with data transfer between the FPGA and the CPU using the serial port. There seemed to be data being lost during the lasts tests where 1000 records are written and read back twice causing the diagnostic to fail. This created a “crisis of confidence” of sorts – I need reads and writes to be reliable.
  • Data transfer between the FPGA and the CPU was much much slower than on a real machine – intolerably so – essentially a “non starter” with respect to much further progress.
  • The copy of T020 that is on the tape is set up to assume that the machine has overlapped I/O. Unfortunately, because of a bug in the FPGA of an unknown origin, the 1410 hits an error stop. This requires resetting the machine, changing the “TAD” at location 1004 to a 1 to suppress testing the 2nd channel, and then restarting at location 2000.

Not having confidence in reading and writing, and with the slowness of PC <-> FPGA transfers was a big concern. So, in August 2024 I began researching to see how I might use Ethernet instead of the 115,200 bps serial over USB that I had been using. That is the subject of the next post!

Xiegu X6100 WiFi Adventures

Top Line

I ran into to major issues in getting my Xiegu X6100 WiFi/WLAN to work on my network under APP version 1.1.9, Sept 14 2024.

Firstly, a minor complaint (well, maybe pretty major), I found that the operation of the various buttons in the WLAN section can be very confusing. Here is what some of the ones that may not act as you expec actually seem to do:

  • WIFI SWITCH: Turns the WiFi radio off or on. One time, though, ONE TIME when I pressed this, it wiped out all of my WiFi settings.
  • CONFIG: This button recalls the settings for the network currently highlighted network from /usr/app_qt/.config/ssid. Otherwise, if the selection has not changed, then at least sometimes (but seemingly not always) it saves the current settings in that same file.
  • CONNECT: After you press CONFIG, this is used to connection to the currently selected network. It can also save settings into the file in .config if the selected network did not change. ALWAYS press CONFIG first, or you will end up wiping out your configuration in /usr/app_qt/.config/ssid
  • MFK Knob: Turning the MFK knob and then pressing it will allow you to select a network. NOTE: DO NOT turn the MFK knob to a displayed ssid and then press the CONNECT button to connect to that network. If you do, it will connect – but it will also overwrite the file in /usr/app_qt/.config file for the selected network. ALWAYS press CONFIG first.

A second minor complaint is that it stores information about WiFi in to different locations. For a given ssid, that information is found in /usr/app_qt/.conf/ssid AND in /etc/NetworkManager/system-connections/ssid.nmconnection and just because the information is in /usr/app_qt/.conf/ssid does NOT mean it gets were it really needs to go in /etc. So, the two can (and do) get out of sync.

The first major problem is that I have found that pretty consistently the radio GUI does not set (or change, on and update) the password in /etc/NetworkManager/system-connections/ssid .

So, if you attempt to connect to your WiFi network from a Xiegu X6100 and it fails to connect, attach a USB cable from the DEV port on your radio and a USB port on your PC, start up a terminal emulator on the . (There are YouTube videos and other places that document this process.) Then look in /etc/NetworkManager/system-connections for a file of your-ssid.nmconnection and look at it with “cat” or “vi”. If it has a password, is it correct? If no, You can fix the password with “nmcli con modify your-ssid wifi-sec.psk ‘my-password’ “

Here is an example the section that has to be set up right with the password in /etc/NetworkManager/system-connections/ssid.nmconnection:

[wifi-security]
auth-alg=open
key-mgmt=wpa-psk
psk=your-wifi-password-goes-here

The second major problem I ran into is that if you want to use a statically-assigned IP address (as opposed to DHCP), then to make it work consistently, I found I had to edit the file /usr/app_qt/.conf/ssid manually. It is important to realize that when you enter the IP address in the IP address field you have to also indicate the network mask – which the X6100 GUI does not seem to support. This will break how packets get routed to and from the X6100 on most networks. It seemed to work best to edit that file while a different ssid is selected in the radio (even if not connected). It found it best to use “CIDR” notation. For most folks, whose netmask is the usual 255.255.255.0, that means entering your IP address as something like 192.168.1.2/24 — note the /24. I used the vi editor to do that. Once you do that, it does display properly. You might also then want to chmod 555 on that file so the GUI can’t change it on you. 😉

If you once set a static IP address, then setting it back to DHCP does not work. You would have to go in and either remove the connection files for that ssid from /usr/app_qt/.config and /etc/NetworkManager/system-connections, or edit them manually.

Here is what it looks like when correctly set up for a fixed IP address in /usr/app_qt/.config/ssid:

[WIFI_CONFIG]
Auto%20Connect=false
DHCP=false
DNS%20Server=192.168.1.1
Gateway=192.168.1.1
IP%20Address=192.168.1.4/24
Password=”your-wifi-password-should-be-here”

And here is what it should look like in /etc/NetworkManager/system-connections/ssid.nmconnection:

[ipv4]
address1=192.168.1.4/24,192.168.1.1
dns=192.168.1.1;
dns-search=
method=manual

(Of course, your DNS server might be different.)

The Journey


In December, 2024 I received a new Xiegu X6100 QRP HF/50 Mhz Transceiver as a gift. Of course, being a techy, the first thing I wanted to do was connect it to my network, as WiFi is supported on the later firmware/software releases. However, I was unsuccessful at APP software level V1.1.9. Though I am aware of a third party GUI for this radio, WiFi is supposed to work with the GUI front end from Xiegu — I just had problems.

After going thru the steps recommended for the radio (at System Settings => WLAN) I found that when pressing the button under “CONNECT” it would try to connect, but fail. I tried all three of my WiFi access points using the radio’s WLAN configuration process – one of which broadcasts its SSID, but to no avail. In every case, when I clicked on “CONNECT” it had a pop up that showed it was trying to connect, but it was never able to do so.

I had learned along the way that one can also connect to the radio to get access to Linux by plugging a USB A to C cable (provided with the radio) to the DEV port on the right-hand side of the radio, and connecting the other end to a PC (in my case Windows). There are instructions and videos availble on the Internet which show how to do this. I used the program “putty” set to 115,200 bps to the port which shows up in Windows as a port named “USB-Enhanced-SERIAL-A CH342 (COM8)” to do so.

I then did what any Linux familiar person would do — look at the messages in /var/log/messages, and found these messages:

Jan 1 00:04:50 XIEGU-x6100 daemon.info NetworkManager[184]: [290.0567] audit: op=”connections-reload” pid=328 uid=0 result=”success”
Jan 1 00:04:52 XIEGU-x6100 daemon.info NetworkManager[184]: [292.8730] audit: op=”connection-update” uuid=”aa6acb02-9ae7-4eac-a1cc-5583af5d5f4c” name=”my-ssid” result=”fail” reason=”802-11-wireless-security.psk: property is invalid”
Jan 1 00:04:57 XIEGU-x6100 daemon.info NetworkManager[184]: [297.3599] audit: op=”connection-update” uuid=”aa6acb02-9ae7-4eac-a1cc-5583af5d5f4c” name=”my-ssid” pid=341 uid=0 result=”success”
Jan 1 00:05:02 XIEGU-x6100 daemon.warn NetworkManager[184]: [302.6258] keyfile: load: “/etc/NetworkManager/system-connections/Redmi_huai1.nmconnection”: failed to load connection: File permissions (100666) are insecure
Jan 1 00:05:06 XIEGU-x6100 daemon.info NetworkManager[184]: [306.0778] audit: op=”connections-reload” pid=345 uid=0 result=”success”
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1394] device (wlan0): Activation: starting connection ‘my-ssid 1’ (87230e25-962c-4a3f-8002-7a489a41a09c)
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1407] audit: op=”connection-activate” uuid=”87230e25-962c-4a3f-8002-7a489a41a09c” name=”my-ssid 1″ pid=350 uid=0 result=”success”
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1430] device (wlan0): state change: disconnected -> prepare (reason ‘none’, sys-iface-state: ‘managed’)
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1498] manager: NetworkManager state is now CONNECTING
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1589] device (wlan0): state change: prepare -> config (reason ‘none’, sys-iface-state: ‘managed’)
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1636] device (wlan0): Activation: (wifi) access point ‘my-ssid 1’ has security, but secrets are required.
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1638] device (wlan0): state change: config -> need-auth (reason ‘none’, sys-iface-state: ‘managed’)
Jan 1 00:05:10 XIEGU-x6100 daemon.warn NetworkManager[184]: [310.1859] device (wlan0): no secrets: No agents were available for this request.
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1863] device (wlan0): state change: need-auth -> failed (reason ‘no-secrets’, sys-iface-state: ‘managed’)
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.1979] manager: NetworkManager state is now DISCONNECTED
Jan 1 00:05:10 XIEGU-x6100 daemon.warn NetworkManager[184]: [310.2154] device (wlan0): Activation: failed for connection ‘my-ssid 1’
Jan 1 00:05:10 XIEGU-x6100 daemon.info NetworkManager[184]: [310.2295] device (wlan0): state change: failed -> disconnected (reason ‘none’, sys-iface-state: ‘managed’)

There are several things to notice here:

  • 1) The message with “audit: op=”connection-update” uuid=”aa6acb02-9ae7-4eac-a1cc-5583af5d5f4c” name=”my-ssid” result=”fail” reason=”802-11-wireless-security.psk: property is invalid”” looks like some kind of configuration error.
  • 2) The message keyfile: load: “/etc/NetworkManager/system-connections/Redmi_huai1.nmconnection”: failed to load connection: File permissions (100666) are insecure” is typical of many many more messages of that sort for various networks that appear to be present in the radio as remembered connections. There are 492 of them on my radio.
  • 3) The message: “device (wlan0): Activation: starting connection ‘my-ssid 1’ (87230e25-962c-4a3f-8002-7a489a41a09c)” appears to have a similar SSID to the network I was trying to connect to at the time (my-ssid) but with an extra ” 1″ at the end.
  • The message “device (wlan0): Activation: (wifi) access point ‘my-ssid 1’ has security, but secrets are required.” is the final message, and is somewhat confusing.

So, I searched the Internetnet for “has security, but secrets are required”, where in I found a page that had a suggestion to delete that existing connection, and then re-add it. https://unix.stackexchange.com/questions/420640/unable-to-connect-to-any-wifi-with-networkmanager-due-to-error-secrets-were-req

So, based on that website I first tried the command “nmcli con“. Whoa – that listed 431 lines of connections (see 2), above). I tabled fixing that, and then did “nmcli d wifi list“. that showed three connection possibilities, one for each of my WiFi networks in my house. So based on what I had read on the website, and what I saw in the messages, I did “nmcli con delete SSID” for each SSID listed.

At some point around then I entered “nmcli dev wifi connect my-ssid” (my-ssid being the SSID) and got a message “Error: Connection activation failed: (7) Secrets were required, but not provided“. That was hopeful, and made sense – I had not provided a password.

So then I then turned off wifi on the WiFi radio with “nmcli r wifi off” and back on with “nmcli r wifi on” and then did “nmcli dev wifi connect my-ssid password ‘my-password‘ (I had to use apostrophes around my password because it has special characters in it that the Linux shell would mis-interpret). That worked. Yesterday.

HOWEVER, the next day, when I went to write this blog post, and in order to reproduce my results, I deleted the existing connections, tried the above commands to connect, it failed to work. So, I went in to /etc/NetworkManager/system-connection and deleted the entry my-ssid.nmconnection . That did not help, either.

I then decided to clean up the 430+ garbage connections the are present in the Linux image. To do that, I made a dierctory with “mkdir /etc/NetworkManager/removed-system-connections“, changed back to folder with “cd /etc/NetworkManager/system-connections” and then did a “mv *.nmconnection ../removed-system-connections” to get rid of the garbage.

I tried a bunch of things at that point, including telling it to connect without a password, and with a password — nothing seemed to help. But it had worked yesterday! WTF!!?? . Time for lunch,. 😉

After lunch, starting with an empty system-connections directory, I tried to connect to my-ssid again, using the radio GUI to set the password. The result was that the file my-ssid.nmconnection had indications that a password should be there – but the password itself was missing. The password is stored somewhere, because the radio does display it, but it apparently isn’t where it needs to be. (Spoiler: It turns out they are stored in files named /usr/app_qt/.config/ssid“)

So, I then entered the password into the connection file using: “nmcli con modify my-ssid wifi-sec.psk ‘my-password‘. THAT WORKED.

I then created a connection for another of my access points, and once again, it left out the actual password. It also did not include the IP address information I entered (this one doesn’t use DHCP). But, having entered the wrong password using the radio GUI I went back and fixed that, and then it was successful.

I then went to the root directory to see if I could find out where else some of this info might be getting saved, using “grep -r ‘part-of-password’ directory-name for each directory in the root directory, / . I then discovered the information stored in a file for each connection, named /usr/app_qt/.conf/ssid

Further testing revealed that when you change the settings on the radio itself, nothing happens at first – it is just on the screen. BUT, if you press “CONFIG” that information gets stored into /usr/app_qt/.conf/ssid but not into /etc/NetworkManager/system-connections/ssid.nmconnection . However, if you press “CONNECT” the information gets copied into both places.

That allowed me to get the X6100 to my network with my static network settings. However, at that point it would only talk to my firewall (which was also its default route.) But my firewall will not route between hosts on my own network. I temporarily fixed this with the command “route add -net my-network netmask my-netmask wlan0″ (A sample for my-network might be 192.168.1.0 and my-netmaks 255.255.255.0 – your network will probably be different.). Once I did that, everything worked. (If I were running dhcp, that routing would have happened automagically.)

It was at that point that I realized there was no way to enter the netmask/CIDR properly in the GUI, and edited the file in /usr/app_qt/.config/ssid to put in the proper information. Once I did that, everything worked fine.

Also, a note about NTP. I found that I had to manually edit /etc/ntp.conf to set NTP up the way I wanted it, stop ntpd (/etc/init.d/S49ntp stop), run ntpdate, and then restart ntpd. Setting the ntp server in the radio GUI did not seem to work correctly.

In Memoriam: R. Hannes Beinert

I learned that my friend R. Hannes Beinert (“Hannes”) passed away during the first day of January, 2024. As he was about eight years my junior, this was quite a shock. Although we had not been in contact for a few years, I still counted him among my friends, and I will miss him.

In the early 1970’s I tended to hang around the University of Wisconsin (UW) Computer Systems Lab (CSL). My friend Paul Pierce, a student at the time, was employed there. The computers at CSL were free to use on a sign-up basis, and time was regularly available. In those early years there were cables that ran between the PDP-11/20 and the Datacraft 6024 to a home-grown switch box that allowed one to switch simple peripherals, like paper tape, a printer, and a card reader, between the two. Hannes, a high school student at the time, would sometimes step on the cables, and we used to call him out on it and tease him mercilessly about it.

A year or two later, UW CSL was running UNIX 6th edition on a PDP-11/45 that was on loan from the Wisconsin state printing office. Hannes adopted the user name “oracle” (later he had an email address “oracle@dodona.com” as well.)

We played D & D together, Hannes, Paul, Steve LaMotte and myself first with Paul Trandel as our dungeon master, and later as Steve took over that role. Hannes and I also played ping pong at Union South. One evening we got into a friendly tussle, and Hannes accidentally ripped the pocket of my winter coat a bit. He felt badly about it, and gave me some of his D&D materials as recompense. Also during those years we took a raft trip down the Wolf river in Wisconsin, in part through the Menominee reservation, including a tumble over “Big Smokey” falls. Hannes, myself and my wife were in the same raft when we went over the falls — something over a 10 foot drop — and managed to stay upright. (In those days there were no helmets, either. 😉 ).

Around that time UW CSL purchased a PDP-11/70 to use for course instructional work, a machine well suited to running UNIX. Trouble was, it had no other software, and the UNIX we had, 7th edition, did not have a standalone program to support the tape drive it had to load the system onto disk, and although a tape drive that would have been supported existed on the CSL VAX 11/780, for some reason it was not a good idea to borrow it. I was already employed by Wisconsin DOT at the time, but we both (mostly Hannes) worked into the wee hours to get it loaded – I wrote the tape read routine, and Hannes the disk write routine. We assembled the code on the PDP-11/20 to get printed listings – the PDP-11/70 had no card reader, teletype or paper tape reader, just a 120cps DecWriter. I left about 2AM, and stopped in about 7:30 AM on my way into work to check in. Hannes had stayed all night and had the UNIX 7th edition booted up. (I used that system to work on Small-C for the IBM mainframe.)

During his high school and college years Hannes also became an accomplished sailor, sailing with the Hoofer Sailing Club. Somewhere along the line, Hannes also served as Fleet Captain for the Hoofer Sailing Club 470 fleet. Later he also raced, along with others in the Hoofer sailing club, on Lake Michigan on a sailboat known as “Marika” owned by Don Stitt, a member of the state’s legislature. In 1989 I had a kind of epiphany with respect to being more active, and Hannes offered to take me and my wife out on “Maria”, the Santa Cruz 33 foot sailboat owned by the Hoofer Sailing Club. (The plan had been to go out on Marika, I had taken the day off, but Hannes had kind of forgotten, and the weather on Lake Michigan that day was a bit windy anyway). I was hooked. A couple of weeks later he took me out on an M-20 Scow (I think it was the yellow one, that I later crewed on in Mendota Yacht Club races) and I was really hooked. I joined the club, and sailed actively for about 20 years – I last went out in 2019 before the pandemic hit. Hannes maintained the UW Outdoor Rentals Mooring field for a few years as well.

During those years Hannes studied and obtained his Masters license with a sail endorsement. He served as crew aboard the sailing vessel Rose (later renamed the Surprise), and he also served as boatswain on the sail training vessel Pogoria (wikipedia) from Poland for a trip across the Atlantic. We both attended the early meetings in the development of the sailing vessel Denis Sullivan, originally sailing out of Milwaukee, as well – that vessel has since relocated to Boston. A bit later Hannes served on the research vessel “R/V Acoustic Pioneer” doing sonar work off the cost of Alaska.

Hannes helped immensely in the acquisition of many of the minicomputers that are in my collection. He drove the trucks as I had no experience with them, and helped me carry equipment down our steps into the basement. Machines he helped with included the Data General Eclipse S/140, the PDP-11/24 (which we hauled out of Bascom Hall at UW), and a number of machines that had been in Professor Marleau’s electrical engineering computer lab at UW – including a PDP-11/20 (which I had used when I was in sch0ol), a PDP-11/40 and a PDP-11/45, and with the PDP-12 as well. Hannes and my friend Pete Mooney also once showed up in the evening with a truckload of gear, including a Data General Eclipse S/130, a Data General Nova 4, a Data General Nova 3 (since donated to the Large Scale System Museum) a Commodore PET and a Cromemco Z-2 S100 system.

One time, while Hannes was out of town, I got a call from his then girlfriend indicating that they were about to throw out a PDP-11/20. I rescued the “guts”, and Hannes later loaded the rack into the back of his parent’s Toyota Corolla station wagon to transport it to my house. I thus named this particular PDP-11/20 as the “Hannes’ PDP-11/20“.

In later years he served as caregiver at home for his mother (whom he referred to as “Mutti”) who suffered greatly with cancer and he continued to live in their house with his father, Helmut Beinert.

Unfortunately over the years we slowly drifted apart, and had only occasional contact. I regret that now, and he will be missed.

IBM 1410 FPGA: Input Check

The next issue to fix was another instruction check, this one after a console input instruction finished where the number of input characters was less than or equal to the number of expected input characters.

The basic problem was that as I/O was ending, the I CYCLE CTRL signal goes active while E CH UNOVERLAP IN PROCESS is also active.

The problem can be seen in this waveform capture:

Instruction Check during completion of console input where the number of characters entered is less than or equal to the number of expected characters.
Instruction Check during completion of console input where the number of characters entered is less than or equal to the number of expected characters.

What made this problem a bit more interesting was that this error did not occur if the number of characters entered was more than the available buffer (i.e., from the address specified in the read instruction up to and not including the group mark with a word mark that marks the end of the input buffer:

NO Instruction Check during completion of console input where the number of characters entered is greater than the number of expected characters.
NO Instruction Check during completion of console input where the number of characters entered is greater than the number of expected characters.

I spent quite a few days looking at this and that and trying this and that, without making much headway. And in the process I discovered a couple of interesting errors in the IBM CE documentation for the 1410.

One thing I noticed was that the logic for an Instruction Check that is shown in the IBM 1410 System Fundamentals manual, S223-2589 and is quite simple would not have caused this Instruction Check, and that the logic in the Instruction Logic Diagrams, R23-2936 does have logic that would trigger an error under these circumstances and is more complex. The latter matches (more or less — more on that later) the ALD and triggers this error from either of the bottom two sets of (ILD) AND/OR gates in the lower left hand corner of Figure 58 of the ILD. (In reality, these are implemented using AND/NOR gates – aka And/Or/Invert gates).

The second thing I noticed was that in the I-O sequence diagram on page 43 of the 1411 I/O Operations Manual 223-2692 depicts +S I CYCLE CTRL indeed overlapping +S E CH UNOVERLAP IN PROCESS – in contradiction to what is on the ILDs.

Finally, in comparing the ILD to the ALD I did spot one error in the ILD. In the bottom most And/Or gate on the ILD, there is an OR gate for signals E CH OVERLAP IN PROCESS and I CYC CTRL. In fact, that one is F CH on the ALD (which make more sense).

So, what to do. I had some concern that the change I made earlier to ALD page 12.12.62.1 to inhibit E Cycle Required during Logic Gate A might be a problem, but thought experiments didn’t bear that out. Also, the condition seemed to be benign, in that once the I/O completed, E CH UNOVERLAP IN PROCESS would be de-asserted. Finally, I wondered it this might be another case where the speed of the FPGA logic for multiple layers via LUTs – look up tables – might be causing a race condition.

In the end, I decided on a simple approach. I created a variant of card type DHL, called DHLJ, with an extra direct input to the NOR gate, using otherwise unused pin K. I then fed in the I-O LAST EXEC CYC signal into ALD logic blocks 4E and 4H, which resolved the Instruction Check.

This is shown in the following timing diagram:

Input Instruction Check fixed by inhibiting an instruction check when IO is finishing up and +S I-O LAST EX CYCLE is active.
Input Instruction Check fixed by inhibiting an instruction check when IO is finishing up and +S I-O LAST EX CYCLE is active.

This isn’t the most satisfactory thing in the world, but given the contradictory nature of the IBM materials, I didn’t feel like I’d be able to sort it out properly – at least for now. (Also note in the above timing diagram the “notch” in +S E CYCLE REQUIRED during Logic Gate A, caused by the earlier fix.)

With this fix, there are no more problems running the 1410 diagnostic CU01C, nor the 1401 Mode diagnostic M011, including console input.

There is still much to do, including replicating the E Channel fix to ALD 15.41.10.1 into the F channel. After that, I think I will spend some time cleaning up console operations, where there are lots of things to change on the PC Support program software side, as well as some hardware issues, like the improper prompt character during the start of a console Display operation (and other operations as well), and some possible issues during address set and storage load and regen operations.

IBM 1410 FPGA: No. 5 sez: Need More Input

As mentioned in the previous post, during testing of the 1401 compatibility of the IBM 1410 I discovered that console input was not working properly for the machine in either 1410 or 1401 mode. The 1411 CPU would accept the characters, but only the first was entered into storage (if that), and pressing Inquiry Release or Inquiry Cancel did not terminate the I/O operation. After some trial and error signal examination, I discovered that the E1 Register Full latch was “oscillating”, and the cause seemed to be a simultaneous set and reset signals.

In the original hardware, this was unlikely to occur, given multiple layers of logic gates, signal travel times on the backplane wiring, and so on. But in a simulation, or in an FPGA the combinatorial logic signals are implemented using look up tables (LUTs) making instantaneously simultaneous combinatorial signals a likely possibility.

Timing Diagram showing problem with E1 Reg Full being set and reset at the same time, resulting in an unstable latch.
Timing Diagram showing problem with E1 Reg Full being set and reset at the same time.

So, how to prevent that? The first, more or less obvious thing, was to condition one or both of the set and reset signals to give one or the other priority. I found that if I gave the reset signal priority (by inhibiting set when reset was active) that console output was negatively affected, because this change affected both input and output.

However, if I added an inhibit from the set signal to the logic block at 5A, so that set for just input had priority, the problem went away – I could type characters into the console and they were properly entered into memory.

But I also noticed that doing the fix that way I ended up with second pulse of +S SET E2 REG during the cycle. While this didn’t seem to cause any real problems, I was nervous about possible future effects. In addition, it left the E1 FULL signal active for longer than it needed to be.

First attempt to fix E1 Set/Reset Latch problem resulting in duplication of +S SET E2 REG
First attempt to fix E1 Set/Reset Latch problem resulting in duplication of +S SET E2 REG

While looking at ALD page 15.62.04.1, which generates signal +S SET E2 REG, I noticed another signal, delayed by 1 IBM 1410 clock pulse, +S SET E2 REG DELAYED. Feeding that into the logic block 5A on ALD page 15.41.10.1 instead of +S SET E2 REG allowed an earlier reset of the E1 REG FULL latch to the time where it really should be happening, and prevented the extra +S SET E2 REG pulse from occurring.

Fix for E1 REG FULL latch problem by using +S SET E2 REG DELAYED
Fix for E1 REG FULL latch problem by using +S SET E2 REG DELAYED

I am a little concerned about the +S E CYCLE REQUIRED being inactive during Logic Gate A, but it doesn’t seem to be causing any problems so far.

However, there is still one remaining issue with console input. If I enter more characters than are allocated in the buffer (terminated by a Group Mark with a Word Mark), the M%T0xxxxxR instruction ends normally. But if I enter fewer characters or the exact number of characters expected, the instruction ends with an Instruction Check, I think because I CYCLE CTRL and E CH UNOVERLAP IN PROCESS are both active at the same time. In the CE instructional text manuals, this check is not present in the logic, however in the ILDs it is present. The question is whether the test should not be implemented the way it is (perhaps by adding some signal to the logic), or if it is just an inopportune appearance of a Error Sample pulse at that time.