COFF September 2023

coff@tuhs.org

10 participants
7 discussions

Re: Seeking Some Japanese Computing Books

by Rudi Blom

I just realised that in HP-UX there are lots of filesets with various language messages files and manpages (japanese, korean and chinese). Normally I don't install these. Therefore I also have no idea what the format is If you're interested I could install a few and mail you a bundle. Just let me know. Take care, uncle rubl -- The more I learn the better I understand I know nothing.

10 months

Smokin' In the Terminal Room

by segaloco

Subject doesn't roll off the tongue like the song, but hey, I got a random thought today and I'd be interested in experiences. I get where this could be a little...controversial, so no pressure to reply publicly or at all. Was it firmly held lore from the earliest days to keep the air as clean as possible in computer rooms in the earlier decades of computing? What has me asking is I've seen before photos from years past in R&D and laboratory settings where whoever is being photographed is happy dragging away on a cigarette (or...) whilst surrounded by all sorts of tools, maybe chemicals, who knows. It was a simpler time, and rightfully so those sorts of lax attitudes have diminished for the sake of safety. Still I wonder, was the situation the same in computing as photographic evidence has suggested it is in other such technical settings? Did you ever have to deal with a smoked out server room that *wasn't* because of thermal issues with the machinery? I hope this question is fine by the way, it's very not tech focused but I also have a lot of interest in the cultural shifts in our communities over the years. Thanks as always folks for being a part of one of the greatest stories still being told! - Matt G.

10 months

Compilation of Known 3B20 Pictures

by segaloco

Good day folks, I just wanted to share a list of links I compiled together of known 3B20(D|S) photographs from various places: WECo Magazine 1982 Q3 p. 8 displays a technician loading a disk pack with the 3B20S bezel in the foreground: https://archive.org/details/westernelectricmagazine_1982_q3/page/8/mode/2up WECo Magazine 1982 Q3 pp. 24-25 display some promotional meeting photos concerning the 3B20S: https://archive.org/details/westernelectricmagazine_1982_q3/page/24/mode/2up WECo Magazine 1982 Q4 p. 4 has a picture of a WECo magtape reader, presumably on a 3B20: https://archive.org/details/westernelectricmagazine_1982_q4/page/n3/mode/2up WECo Magazine 1982 Q4 p. 5 has a picture of a 3B20S and one disk drive: https://archive.org/details/westernelectricmagazine_1982_q4/page/4/mode/2up WECo Magazine 1983 Q2 p. 28 Figures 1 and 2 display a 5ESS and 3B20S respectively: https://archive.org/details/westernelectricmagazine_1983_q2/page/28/mode/2up WECo Magazine 1983 Q3 pp. 4-5 displays a 5ESS with a few panels open at a low angle: https://archive.org/details/westernelectricmagazine_1983_q3/page/4/mode/2up WECo Magazine 1983 Q3 p. 13 displays a technician swapping out a card as well as a disk pack on a 5ESS: https://archive.org/details/westernelectricmagazine_1983_q3/page/12/mode/2up WECo Magazine 1983 Q3 pp. 22-23 display some folks working on DMERT/3B20D stuff at some VT100s: https://archive.org/details/westernelectricmagazine_1983_q3/page/22/mode/2up And from a Facebook group I came across in a Google image search: 2 3B20S units in a computing center: https://scontent-sea1-1.xx.fbcdn.net/v/t39.30808-6/277168646_10159734053426… A 5ESS showing the 3B20D end of it: https://scontent-sea1-1.xx.fbcdn.net/v/t39.30808-6/270140634_10158822329508… I can't overcome my anti-Facebook-ness to try and get in touch with that group...but it seems like some folks there might appreciate COFF and TUHS if they don't know about them. If you're a member of the Zuckerbook and are so willing, you might consider reaching out to some of those folks with links to the mailing lists. I don't know how etiquette on those sites work tho, so ymmv. That should be all the 3B20 content I've come across the past few months. I've been trying to drum up more photographic evidence as there isn't much. The same can be said for other non-3B2 machines in the 3B line, I only know of a few pictures of a 3B15 and I think one I've ever seen of a 3B5, I wouldn't know another picture of a 3B5 if I did see one. Not a whole lot of computing hardware with that little Bell logo on it, it's nice to see when stuff does turn up. - Matt G.

10 months

Seeking Some Japanese Computing Books

by segaloco

Good morning, I am going to pick up a few Japanese computing books to get more familiar with translating technical literature and figured I'd see if anyone here has any of these before I go buying from randos on eBay (Not sure all of these exist in Japanese): The C Programming Language (Either Edition) The C++ Programming Language Any AT&T/USL System V Docs The UNIX System (Bourne) John Lions's Commentary Any Hardware Docs from Japanese shops (Sony, NEC, Sharp, JVC, etc) that have English counterparts (e.g. MSX architecture docs, PC-*8 hardware stuff) Thanks all! - Matt G. P.S. Even less likely but any of the above in Chinese I would be interested in as well. Many Kanji and Hanzi overlap in meaning so while it may be like trying to read Chaucer with no knowledge of antiquated English, translation between Hanzi and English may help the Kanji situation along too.

10 months, 1 week

Re: [TUHS] Re: The AWK Programming Language, 2nd Ed.: What's new?

by Anthony Martin

Warren Toomey via TUHS <tuhs(a)tuhs.org> once said: > The history of Unix is not just of the technology, but also of the > people involved, their successes and travails, and the communities > that they built. Mary Ann referenced a book about her life and > journey in her e-mail's .sig. She is a very important figure in the > history of Unix and I think her .sig is entirely relevant to TUHS. Are you fine with everyone advertising whatever views and products they want in their signatures or would I have to be a very important figure? If I want to say, for example, that the vast amount of software related to Unix that came out of Berkeley was so harmful it should have a retroactive Prop 65 label, would that be okay to have in my signature? Cheers, Anthony The vast amount of software related to Unix that came out of Berkeley was so harmful it should have a retroactive Prop 65 label. [Quote from some person completely unrelated to Unix.] [A link to buy my children's picture book about the tenuous connection between Unix and the NATO terror bombing of Yugoslavia, direct from Jeff Beelzebub's bookstore.] End of signature. Sorry Warren, I couldn't help myself. I was "triggered" just like Dan Cross, previously in that thread, who could not stay silent. "Silence is violence, folx." - Sus of size (a.k.a. postmodernist Porky Pig) Sent to COFF as Dan should have done.

10 months, 1 week

C compiler in 512 bytes

by Warner Losh

This appeared in my news feed and hacker news. https://xorvoid.com/sectorc.html Warner

10 months, 3 weeks

Dragon Quest Disassembly

by segaloco

Howdy all, I've made some mention of this in the past but it's finally at a point I feel like formally plugging it. For the past few years I've been tinkering on a disassembly of Dragon Quest as originally released on the Famicom (NES) in Japan. The NA release had already gotten this treatment[1] but I wanted to produce something a little more clean and separated: https://gitlab.com/segaloco/dq1disasm Another reason for this project is I've longed for a Lions's Commentary on UNIX-quality analysis of a scrollplane/sprite-driven console video game as I find generally analysis of this type of hardware platform lacking outside of random, chance blog posts and incredibly specialized communities where it takes forever to find information you're seeking. In the longer term I intend to produce a commentary on this codebase covering all the details of how it makes the Famicom tick. So a few of the difficulties involved: The Famicom is 6502-based with 32768 bytes of ROM address space directly accessible and another 2048 bytes of ROM accessible through the Picture Processing Unit or PPU. The latter is typically graphics ROM being displayed directly by the PPU but data can be copied to CPU memory space as well. To achieve higher sizes, bank swapping is widely employed, with scores of different bank swapping configurations in place. Dragon Quest presents an interesting scenario in that the Japanese and North American releases use *different* mapper schemes, so while much of the code is the same, some parts were apples to oranges between the existing and new disassembly. Where this has been challenging (and a challenge many other Famicom disassemblers haven't taken) is getting a build that resembles a typical software product, i.e. things nicely split out with little concern as to what bank they're going to wind up on. My choice of linker facilitates this by being able to define separate output binaries for different memory segments, so I can produce these banks as distinct binaries and the population thereof is simply based on segment. Moving items between banks then becomes simply changing the segment and adding/removing a bank-in before calling out. I don't know that I've ever seen a Famicom disassembly do this but I also can't say I've gone looking heavily. Another challenge has been the language, and not necessarily just because it's Japanese and not my native language. So old Japanese computing is largely in ShiftJIS whereas we now have UTF-8. Well, Dragon Quest uses neither of these as they instead use indices into a table of kana character tiles, as they are ordered in memory, as the string format. What this means is to actually effectively manage strings, and I haven't done this yet, is one needs a to-fro encoder that can convert between UTF-8 Japanese and the particular positioning of their various characters. This says nothing of the difficulty then of translating the game. Most Japanese games of this era used exclusively kana for two reasons: These are games for children, so too much complicated Kanji and you've locked out your target audience. The other reason is space; it would be impossible to fit all the necessary Kanji in memory, even as 8x8 pixel tiles (the main graphic primitive on these chips.) Plus, even if you could, an 8x8 pixel tile is hardly enough resolution to read many Kanji, so they'd likely need 16x16, quadrupling the space requirement if you didn't recycle quadrant radicals. In any case, what this means is all of the strings are going to translate to strictly hiragana or katakana strings, which are Japanese, but not as easily intelligible as the groupings of kana then have to be interpreted into their meanings by context clues often times rather than having an exact definition. The good news though is again these are games for children, so the vocabulary shouldn't be too complicated. Endianness occasionally presents some problems, one of which I suspect because the chip designers didn't talk to each other...So the PPU exposes a register you write two bytes to, the high and low byte of the address to place the next value written to the data register to. Problem is, this is a 6502-driven system, so when grabbing a word the high byte is the second one. This means that every word has to be sent to the PPU in reverse when selecting an address. This PPU to my knowledge is based on some arcade hardware but otherwise was based on designs strictly for this console, so why they didn't present an address register in the same endianness I'll never know. It tripped me up early on but I worked past it. Finally, back to the mappers, since a "binary" was really a gaggle of potentially overlapping ROM banks, there wasn't really a single ROM image format used by Nintendo back in the day. Rather, you sent along your banks, layout, and what mapper hardware you needed and that last step was a function of cartridge fab, not some software step. Well, the iNES format is an accommodation for that, presenting the string "NES" as a magic number in a 16-byte header that also contains a few bytes describing the physical cartridge in terms of what mapper hardware, how many banks, what kind, and particular jumpers that influence things like nametable mirroring and the like. Countless disassembles out there are built under the (incorrect) assumption that the iNES binary format is how the binary objects are supposed to build, but this is simply not the case, and forcing this "false structure" actually makes then analysis of the layout and organization of the original project more difficult. What I opted towards instead is using the above-described mechanism of linker scripts defining individual binaries in tandem with two nice old tools: printf(1) and cat(1). When all my individual ROM banks are built, I then simply use printf to spit out the 16 bytes of an iNES header that match my memory particulars and then cat it all together as the iNES format is simply that header then all of the PRG and CHR ROM banks organized in that order. The end result is a build that is agnostic (rightfully so) of the fact that it is becoming an iNES ROM, which is a community invention years after the Famicom was in active use. Note that this is still an ongoing project. I don't consider it "done" but it is more usable than not now. Some things to look out for: Any relative positioning of specific graphic data in CHR banks outside that which has been extracted into specific files is not dynamic, meaning moving a tileset around in CHR will garble display of the object associated. A few songs (credits, dungeons, title screen) do not have every pointer massaged out of them yet, so if their addresses change, those songs at the very least won't sound right, and in extreme circumstances playing them with a shift in pointers could crash the game. Much of the binary data is still BLOB-afied, hence not each and every pointer being fixed. This will be slow moving and there may be a few parts that wind up involving some scripting to keep them all dynamic (for instance, maps include block IDs and such which are ultimately an index into a table, but the maps make more sense to keep as binary data, so perhaps a patcher is needed to "filter" a map to assign final block IDs, hard to say.) Also, while some data is very heavily coupled to the engine, such as music, and as such has been disassembled into audio engine commands, other data, like graphic tiles, are more generic to the hardware platform and as such do not have any particular dependencies on the code. As such, these items can exist as pure BLOBs without worry of any pointers buried within or ID values that need to track indices in a particular table. As such these flat binary tiles and other comparable components are *not* included in this repository, as they are copyright of their respective owners. However, I have provided a script that allows you to extract these binary components should you have a clean copy of Dragon Quest for the Famicom as an iNES ROM. The script is all dd(1) calls based on the iNES ROM itself, but there should be enough notes contained with in if a bank-based extraction is necessary. YMMV using the script on anything other than the commercial release. It is only intended to bootstrap things, it will not properly work to extract the assets from arbitrary builds. If anyone has any questions/comments feel free to contact me off list, or if there is worthwhile group discussion to be had, either way, enjoy! - Matt G. [1] - https://github.com/nmikstas/dragon-warrior-disassembly

10 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

COFF September 2023