 My nice new brother WP1 word processor. I could connect the Raspberry Pi up to the UART. Sadly, this turns out not to be viable. This is a very cheap PsoC 5 development board and wire that up. We now have nearly all of the Berrylog stuff working. I think that is it and nothing has happened. So I think my status registers are not working. My appbit assignments are all overlapping. I think this might work. And then next time we'll come back with some Z80 machine code. Here we are back in Linux, living the good life with Vim. And we're going to write a simple terminal program that reads bytes from our interface and writes them to the console. I've done all the setup with the build system. This is going on top of my CPM-ish system, so it's actually generating when I do a build a bootable disk image that I can write to floppy and then immediately boot, which is nice. And here is our stub program. Okay, how is this going to work? Well, it's extremely simple. We are going to... This is the wrong page. This is the CPM documentation. No, it's not. That's Reddit. What's that doing there? Here we go, BIOS entry points. We're going to use the three BIOS console entry points to talk to the console and we're going to do direct hardware access to talk to the interface. So, we're actually going to have a loop. The program starts right at the top with no initialization. It's not going to be a complicated program. And what we want to do is to test to see whether there is anything on the console, that is the user has pressed a key. To do that, we want to call the BIOS address plus 06. Addressers library here has contained the address of BIOS, so this should do it. So that will con st. Sample the status of the currently assigned console device and return ff in register a if a character is ready to read and 00 if no console characters are ready. So once we've done this, we want to test a simply doing all with a will set z if it's a zero and then we are going to call do a conditional call to a routine that we'll write later called key pressed that will actually fetch the key from the keyboard and write it to the interface. Next, we want to test the interface. So I have my piece of paper. I have my piece of paper. So in order to test to see if there is a key pressed, we want to read port for one into a and with a mask value to leave just the read status bits. That's three. That is the bottom two bits and then we are going to compare with one which is iris readable and if this is true that says z, I believe we're going to call and then we call our loop routine. Okay, let's actually invert these. Oh, and that should be a Okay, and this does not build because I think we need to do it this way around. This is correct, and I've been using too too much six or two codes so you don't do hash signs. Okay. Right, so this is no longer calling a routine. We're actually going to put the routine to do this here. So to read the key from the keyboard, we are going to call con in which is at BIOS plus 09 and then let me think actually we are actually going to test to make sure the interface is writable first. So to get the the right state we want so there's four bits the bottom two bits are the read status the top two bits are the write status so that is going to be OXC compare that with zero right, so we'll only get to here if we know that the interface is writable so we can immediately write the value to the the value that we just read from the console to the output buffer then we want to mark the we want to tell the interface that we've done it like so now we want to wait for the interface to switch to the done state so done state is 8 if it is not zero loop now we acknowledge that we've seen done like so done to acknowledge data and That should be our right code. That was surprisingly non-complex Okay Now we do the read side of things We know that we're in the readable state so all we need to do is to read the data byte and then call con out write console character out character sent from register C So that's going to be C B base plus It's con out OC we now we need to set the We need to tell the interface that we have done the read So that is one We read it's really knowledge data Come right, and then we do a very similar Loop we actually want to compare against Read status done which is 2 this is Read status done is Not 8 it's 2 it's right acknowledge done. That's 8 wait No, that is that is 8 Yes, read read status done is to write status done is 8 Read status done. Here we go. It's 2 otherwise loop then we Want to send a Read acknowledge done and fall through what is this not liking Okay, we can't read into C. So that should do it Okay, and I think that is our program It's probably not gonna work now There are issues which is the primary the primary issue is That while we are spinning here waiting for WS done. We are not waiting for We're not acknowledging bytes coming in from the interface That's fine because we don't expect to be there for very long The BIOS interface in CPM is rather limited so Con ST here will let you test for a keeping pressed but There is no way to test to see whether the output is blocked or not So it's possible that this may take a reasonable amount of time still very little I mean the the longest time this will take to execute is to clear the screen and we're not in a frame buffer so that should be quick and Our actual compiled program should be in Brother Tools Peter That's him. It is a whole 65 bytes That's it. So Let me just go and grab the floppy disk from the workbench Stick it in the drive and Use flux engine to write it. I already have a command present. So Okay, that's finished the right. So now we take it back to the workstation and see if it works Well, I have discovered one slightly disturbing thing which is as you can see the computer is running Even though I have in fact disconnected the power it's being fed from the interface here via USB so well My laptop seems to be quite happy about Doing that, but it really shouldn't Anyway, let us Hold down code. No, wait, hang on. Let's put the floppy disk in the drive first Hold down code and queue and press the reset button. Oh, let's turn the real power on first. Shall we? Let's try that one again Good and we're booting There is our program called pterm. So let's try it Okay, it's loaded. So if I type stuff should come out on the serial terminal Well, that was looking good up to a point Right. What happens if I type in the serial terminal? again, that worked up to a point So it's clearly wedged somewhere and I don't know where or why interesting and let me Reboot that and have another go Yeah, that noise is because the drive isn't coming up to speed correctly Let's try the serial terminal first. Shall we? Right. Nothing is happening there. Let's try the brother And now nothing is happening there interesting That makes me suspect that the Board here has crashed somehow In fact, I believe that we still have the We still have the blue light that's supposed to toggle whenever The status register is fiddled with Okay, um Let's simplify pterm and try that again, I think Well, this isn't Linux. This is back into Windows again because I realize that Two important things one is they need to put all that State machine tracing back into this And the other is there that there is in fact no way to reset the interface So we're going to put in a reset acknowledge bit When this is set Then regardless of what states the state machine is in We will always go back to the initial state this way we avoid issues where The client thinks the interface is in one state, but the The board is in another Um, and I've also modified pterm to do this on startup So let's add some tracing We go through and insert all the Debug tracing that I foolishly took out before To r s done Done to r s idle writable writing writing to w s done and finally w s done To w s writable Okay, so we program this And then it's back off to the workbench to see what happens All right I've just started pterm and as you can see the interface has says reset So if I press a key on the brother We go from writable to writing it prints a cue writing to done done to writable Oh And it stopped working It's gone writing to done But it hasn't gone Done to writable now Remember that earlier issue where it seemed to be dropping occasional Acknowledge bits. I wonder if it has done that That would be annoying if so But we should now be able to reset the board Once the disk drive spins up It boots We run pterm And the interface reset. So let's now try pressing keys on the serial terminal Right and now it's wedged I think That actually looks suspiciously as if pterm is stuck waiting for w s done And it's not doing anything else which is why it's not responded to the Read state So I think I need to reboot the desktop and go and have a look at what pterm is doing Well, I discovered that my phone had in fact run out of disk space. So I may have lost the last few bits of video recordings, but Everything is better now. So we start up our pterm And we see it reset on the Serial terminal So now I press a key and What that is telling me I can see the I can see it go through in the serial terminal. It's gone all the way back down to writable What I can see here is w means it's in the right delay loop The digit following is the state of the interface. So zero means that it's in writable which is Yeah, okay, that's plausible So what we did was we wrote the byte to the buffer We Then sent the the ac bit to tell it that we had done the write and then we started looping So we expect to see Yeah, it's stuck in writable until the interface processes as the ac bit At which point it goes to state writing which is a four And then that loops until it goes to done Um, yep, that is exactly what I would expect to see. So let's try a few more Okay Keeps working Okay, that's interesting um So I pressed A w at that point. I can see that it the we're still in the writable state according to the interface That mess that's appearing out on the screen is because it's Constantly updating it's stuck in Um In the the weight loop Uh, the only thing I can see coming out is lots of zeros. So uh, it's Yeah the That is correct The brother is seeing the interface is in state zero, which is writable Which is exactly what we see in the serial terminal However, it's never switching to writing This suggests to me like the ac bit has been lost That's annoying Anyway, I believe this to be a very log problem. So let's reboot the desktop again So I actually think I have a solution Although I'm not quite sure why this works So I went and actually read the documentation for the status reg And I found that when you're in sticky mode Then the input is sampled when clock goes high Which means that I didn't actually need the edge detector I can feed the output enables directly into the status register via a sync block To align the clock correctly And it seems to work so I'm still not really sure what's going on with that Because with the edge detector present We should get a pulse which has got a leading edge and a trailing edge so possibly Possibly the data isn't arriving at the status reg when the clock when the pulse shows up Which is peculiar Because I would expect the clock to be more delayed because it's got to go through the sync block Than the actual data, which is coming directly from the data pins But anyway, if I program this then this happens So we start up p-term as usual And now we can type And you can see characters showing up in the middle of the debug tracing On the serial terminal and you can see lots of spam coming from my p-term tracing on the brother And if I hammer the keyboard It does not lock up And likewise if I go over to the serial terminal And I type there And once again, I keep forgetting to put the mouse pointer in the right window Then you can see stuff come out on the brother side And I can hammer the keyboard there And it doesn't lock up and in fact I can hammer both keyboards And everything seems to work fine Of course, this is full of tracing So the next thing to do is to remove the tracing from both the interface and from p-term And see if it still continues to work Okay, let us try it Come on Okay Yes, I am not So convinced. I mean it's it's mostly working But you can see in the serial log in the serial terminal That it's sometimes getting characters wrong. It appears to be Repeating the previous character Rather than Using the one I just typed Okay, let's try typing in the serial port Again, I need the right window Okay, that missing m was my fault That's not bad. I don't think there are any problems there Hammering the keyboard doesn't produce any Lockups there hammering the keyboard here Doesn't use any lockups there doing them both ways at the same time seems to work fine So yeah, there is clearly a problem This is me typing two letters Alternately and you can see it is sometimes getting it wrong What it doesn't seem to be doing is inserting spurious characters or missing characters, which is good Okay, so This seems like a good place to stop for now. I will have to debug this later, but this is now Mostly working unlike the camera focus on the Uh Brother video Yeah, this is a phone. It doesn't really like Videoing this. Oh, well, this is the video I have. So this is what you're seeing Okay See you next time