Some of my problems with input are still around timing - but I now have Adventure working on my 4052!
I found some Commodore 64 characters with ASCII values above 127 in my data files - I posted the new SD card image 7 on Store.
That's good news!. I just tried to run your program file no. 53 in "Adventure" as suggested. Unfortunately it didn't run but that seems to be down to memory (or rather shortage of it). I got the following:
MEMORY IS FULL IN LINE 16 - MESSAGE NUMBER 39
I ran MEM and it returned 308. That seemed odd considering the file is 21kb long so I deleted the program from memory and MEM returned 30699. I then loaded up file 53 again and MEM returned 8963. After another RUN attempt I got the same as above. There is evidently insufficient space to DIM the variables in that statement.
I then tried file 51 which did run and created files 0-9 but stopped on file 10. The output is shown in the photo. Yes, the PRINT command is present on the emulator. It was added in version 05.34. At present it writes to files marked 'DATA' but this will require amending to further distinguish between files of type ASCII DATA and type BINARY DATA.
Support has also been added for CALL "BSAVE" and CALL "BOLD" which require the Binary Program Loader cartridge on the 4051. The command CALL "BSAVE" writes to files of type type NEW or BINARY PROGRAM. In the same way that SAVEing to NEW renames the file to ASCII PROG, BSAVE renames a NEW file to BINARY PROG. The counterpart, CALL "BOLD" reads from type BINARY PROGRAM.
Detection of IFC to clear the interface to idle state has also been added.
I am holding fire on uploading it until I have had the chance to fully analyse the information in your latest post and LA traces. Thank you for the providing the details.SRQ - this seems very odd. I am now using the same adapter board and SRQ goes HIGH on mine and stays HIGH on all the traces. When you read the LA trace was anything else connected? BTW, the layout I created uses direct writing to Arduino ports to change pin states but doesn't use interrupts.
Thank you for providing the traces and details of your captures. I have uploaded 0.05.40 so you can test whether the IFC handling works and helps at all. Once I have more fully analysed the details in your post (e.g. the CD issue), there may be other amendments.
Incidentally, adding CALL "BSAVE" and CALL "BOLD" was an interesting exercise as both commands use the same secondary address number 17 (0x71). It turns out that it is possible to support more than one command on a singe secondary address. In this case CALL "BSAVE" is a listen command and CALL "BOLD" is a talk command so it was just a matter of determining whether the command was asking the emulator to talk or listen and calling the appropriate function. I imagine that CALL "BAPPEN", which also uses the same secondary address, can further be added because it adds line number parameters so on detecting those, the emulator would modify the behaviour of the function that responds to BOLD. We then end up with 3 commands on the same secondary address.
Well, it occurred to me that a similar approach could be applied to the CD command. Currently PRINT@5,9:"directory" sets the working directory. I could be set up so that INPUT@5,9:A$ also reads back the current directory name.
Another idea that ocurred to me was to have the PRINT command produce output on the terminal screen. In the same way that you can send a listing to a printer, you could sent it to the PC screen or over serial to somewhere...