Shmuel, all Well it is true that 360 I/O involved a separate channel processor that shared memory with instruction processor, and it required handling interrupts to determine status of I/O request. Some computers just had byte I/O handled by instruction processor.
Don Higgins [email protected] www.donhiggins.org -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Seymour J Metz Sent: Sunday, December 20, 2020 10:58 AM To: [email protected] Subject: Re: S/360 emulation in PC/370 Any idea why Peter found S/360 I/O alien? I certainly thought that it was conventional when it came out. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Don Higgins [[email protected]] Sent: Saturday, December 19, 2020 10:13 AM To: [email protected] Subject: Re: S/360 emulation in PC/370 All Back in 1980-1981 I wrote PC/370 first in z80 assembler and then ported it to 8086/8087 in 1995. The last shareware release was in 1989 and then I sold all rights to Micro Focus in 1993 before I went to work for them as system software engineer for 9 years before retiring. PC/370 ran on MSDOS and included 360 assembler, linker, and emulator. The coding was relatively easy in z80 because both architectures were byte oriented. As for I/O, I did not depend on SIO and CCW's. Since it ran under MSDOS, I just used user SVC's to route I/O between host I/O and 360 svcs. Here is link to PC/370 up to z390 history: http://secure-web.cisco.com/1TKNAMNAtRkOczWfRUdTeydpUzZfPXpVJoL2TSv8xWtKE3ME ebnhb9QaLt5zx2A5xz15e9CZ3-IvY1tzUOttoEEp6Ty-zVdoccV_sVE31r3N-F2gYkuXhJCyFM2d 8GQJER7vc0QtHWQcJJcJ9p8fA99_VoCYRtZQ4ptAKG-TmV5j132DSSl48EkhipD-ZYNlYuX7MxJY TW7ijOUY_EgexSg1aI4x8Y7GqBdMlnLfibT8lKMtTIuaBRisEMwfjEDB00g__1juwWmwsbKlxnAr 1jVVb2zRQpOaEmzknv_N-fMp-VFcz8bwNJgKdraXVSBZImOHOexP2ETXAsDWqI45VLbDm6QGkIOQ zXEW7d47qrFG749fTTMNKUGZj6xwzLoVHQ9LrcY9ioFg0A4pPyvnMy5QKHggJwNkYQWGYoaiTW2y e17BE500m-Sr6MfR3cIO4/http%3A%2F%2Fdonhiggins.org%2Fpc370.htm Don Higgins <mailto:[email protected]> [email protected] <http://secure-web.cisco.com/1djWg7bFMihmJoRJFmnpEJqY-uGK0TPJZtDCFG5RIikxrAU snl9JIikxnPd9oHx_B25Ser1S8MPNZl_CsNkFKWYB0HHW8GZTrvT6qxNCOOwOMIBlWhRYcZ-rtuw o7dxM8xCALkKO8fsT5i5Kxwi0YUyU5ZqZVpjI6ZzYvDvHGqS_b0LtfqfWy0elnRRDqcVtTqSTDfJ JcPNmqVIDhRucwmRszj8rot9iCjTnjECTs9NFxjvzFZZAJgqnoddrBh3DP0k5YaxzHDCGA4IUJRN -g4lD71CXCu93GC6IPQ3pbzL4mLruy1k1-UPSGOpwBXDFcwUIS0Vfb544aycVUWECH3am4gYt3-- 2MXFp1ZN0gi8CRdsFZVnFdYIvTlQSibEekX5VfQSbniULzGP_Dcz9J-OjmQ013j-zJ3pEEWmJh3P emKPxSu802dOF75P1vDdbV/http%3A%2F%2Fwww.don-higgins.net%2F> http://secure-web.cisco.com/1fFUiiBBj23N3IGPcP_QlCRtYdGzcwyL87X-ofmWZJCFL6Dp _yNHDulTdha45EDqKpX7RF1c8buB0xJhKopTfENyhe46VHA4aBey13uJV0G7Ve9pgUu5VlCUcxJK 1-pJsEEXRiWLZKR-dIDgJvXUaPjsJQ3vbDmBVpz4kVJx7KfmIba0zxlxf96GY9pHjdHAmfuAs6e- myzHLz9dE2IJxNt8dD32KJFfxy2S_WQ1uofD-ECq6vtQnIBvl8_qCZuZ1UeFfuHJ49YuRuiW0bS1 XfNK7Lz2kyHcvbESFnyxizqlM0-37EK2v_6L-Q8bfLsT3NHn4jQce4C2UGXfjgg2R2Uicecls3pN 636geC7RfqESxXQWfqquAaJJOzZh1SeBOkYLc3_qcJfj9hfICFuACEDdP9JDVrQeRhN3FTuOV8RI CJlgIxq_0S1Me3YGhSKiS/http%3A%2F%2Fwww.donhiggins.org From: [email protected] <[email protected]> On Behalf Of Peter Lund Sent: Saturday, December 19, 2020 7:25 AM To: [email protected] Cc: z390 <[email protected]> Subject: Re: S/360 disassembler -- not that hard On Sat, Dec 19, 2020 at 1:10 PM <[email protected] <mailto:[email protected]> > wrote: Peter, I would say the 360 CPU is straight forward to emulate. Yep, that is my impression, too. And much easier, in many respects, than a Z80 or a 6502. They both had undocumented instructions and the Z80 had 2 undocumented flags. To make it even more fun, it has a single instruction that lets 2 bits of an undocumented internal register bleed through to the those flags. And in order to be truly useful in a typical machine emulator, the CPU emulator would have to be cycle accurate and generate wait states correctly and what not. Typical emulated machines also had fun things like bus contention leading to slightly slower execution for some addresses (at some periods, relating to the TV output) or bytes being misread from the data bus. Or they might have had a CPU and certain peripherals operating at different frequencies with all the fun that entails. The S/360 is much cleaner, because I don't have to implement a specific model with all its quirks. I can implement it in the pristine, idealized form. What might be more challenging is the IO. Yep. But mostly because the entire concept is so alien, or at least is *presented* in such an alien way. It really isn't all that different from the way a modern NIC, disk, or GPU works. The Hercules approach is to basically treat each device as if its on its own channel, so it never returns channel busy. And I'll likely do the same. I want this emulator to be simple, so it won't emulate more hardware than strictly necessary. You might find this useful:- https://secure-web.cisco.com/1PPIENJLyxTgz_zFzm_WLnuCWDksvrjFMmRGL0idRE3An0z Y9RHRwR1aIzfh8kuY0f5goHFe3mvxUdqo2ziP4SLHOnWgrRV4CO_2-Z2-7XIqTu3gzRP_Nv3L-U3 XEFRvR_xTo28cO_nCrFV73dNzLQ5B7ZNxq-SxNRa6_yMovFtm3kZr0iwSre5NE7nDCoaUHatVEB- uSblR9b9qsQoQdKE4pfjAohLBnwheYi8Z1P0GmXQpnww7FwRLw9xqjVe1NlR5t38DRV7R1sqZpJS COdjBQd1mcm6Ughy1ST48xcxmcJSfVW_XEgmD4fWxkS06D-GmrlrzkQcolcJi47b0QVHAa3-A6xr wXsYqiDgKRVXDEjkNMixRQmePYU4kQWVAU9EpExWvQ2Fg_hYlxrpq7jHF1SY2euyHnHpv39RCVYD eq9lrAz0af32111zW96L1J4VZus5pJOJDwszSg76PO5Q/https%3A%2F%2Fgithub.com%2Fs390 guy%2FSATK Almost certainly, yes. Thanks! -Peter -- You received this message because you are subscribed to the Google Groups "z390" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/d/msgid/z390/CAMV2NWVSP8x0PpMp87FrcKEXo-fn9Dg3_ce5 8CAQQZawt%3DQpjA%40mail.gmail.com <https://groups.google.com/d/msgid/z390/CAMV2NWVSP8x0PpMp87FrcKEXo-fn9Dg3_ce 58CAQQZawt%3DQpjA%40mail.gmail.com?utm_medium=email&utm_source=footer> .
