cr1901 changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, CD/floppy disk theory of operation, and the 68k CPU are also on-topic. Channel logs: https://libera.irclog.whitequark.org/~h~yamahasynths
nikitalita has quit [Remote host closed the connection]
Degi_ has joined ##yamahasynths
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<andlabs> https://www.beep-shop.com/ec/products/detail/AE-2--1722 oh cool someone actually did write a repair guide for my model of X68000; even if I have to learn japanese ot read it =p
<NiGHTS> X68000 (初代) 修理マニュアル / 武者返し.com|BEEP ゲームグッズ通販
<myon98> Oh a website of BEEP, didn't know about that
<myon98> I'd love to own a x68k one day, I don't know much about it but I just think that the concept of a DOS like OS on a processor with a linear address space is cool
<myon98> probably related to how straightforward was it to adapt GCC (or as I've read so)
<andlabs> given the number of gcc books for the X68000 it must have been very easy yes =P
<andlabs> and gcc is still keeping its 68000 support so it might even be possible to run current gcc on it, maybe
<qu1j0t3> wellllllllllllllll
<qu1j0t3> that will definitely come down to address space and physical ram,firstly;-)
<myon98> In my experience with DJGPP newer GCC unfortunately requires tons of RAM so that might be the limiting factor, like more than 32MB for version 5 or later
<myon98> But a cross compiler like Retro68 with all the modern features available might be a possibility, while not having to worry about extenders or 16-bit segments like on x86
<andlabs> oh yeah
<andlabs> I recently tried building MAME with clang instead of gcc and oh wow the memory usage was significantly reduced
<andlabs> giant template-heavy files like emumem_aspace.cpp that cause gcc to lock my VM up fly through clang
<andlabs> as for the beep website that's how I first learned about them by name, since my friend released some gmaes in japan through them
<andlabs> myon98: this Retro68? https://github.com/autc04/Retro68
<NiGHTS> GitHub - autc04/Retro68: a gcc-based cross-compiler for classic 68K and PPC Macintoshes
<myon98> I only knew BEEP from the cozy store in Akiba, when I went there a few weeks before they were displaying a working TAM
<myon98> andlabs, yeah. I do have a couple of classic Macs that I would like to program for but the environment is so different and it's very difficult to find documentation compared to WinAPI
<andlabs> cool
<andlabs> this looks potentially useful
<andlabs> and yeah as for documentation you might have to find some ancient PDFs or archives of early-2000s Apple Developer Connection
<qu1j0t3> myon98: Hm, Inside Macintosh should be very easy to get
<qu1j0t3> and yeah all those dev cds and ETOs have been imaged, shouldbe online
<qu1j0t3> it's one of the easiest platforms regarding documentation
<qu1j0t3> availability of tools should be no problem either; CodeWarrior, MPW, etc
<andlabs> I wonder how sophisticated the classic APIs are
<qu1j0t3> similar to Win32
<andlabs> it would be very funny to have libui run on macOS 9 and macOS 10.8 but not 10.0-10.7
* qu1j0t3 was Mac dev from ~ 1986-
<myon98> Thank you, I downloaded Macintosh Toolbox Essentials and More Macintosh Toolbox a while ago, I thought it was a little bit terse for a newcomer like me, but it's probably more due to me being unfamiliar with it. I'll look into it more.
<andlabs> is Inside Macintosh still the doucment of choice for OS 9?
<andlabs> likewise for Macintosh Toolbox Essentials whose official Apple PDF is from 1992
<qu1j0t3> why not? it's not like OS 9 has changed :)
* qu1j0t3 started on System 6
<andlabs> system 6 in 1986? =p
<andlabs> ...huh sys6 was 1988, that's still older than I thought it'd be but okay
<qu1j0t3> hm, interesting
<qu1j0t3> must have been system 5
<qu1j0t3> irecall it was Finder 1.1
<qu1j0t3> yeah, System 5
<andlabs> but sure
<qu1j0t3> there wasn't much visible change
<qu1j0t3> System 7 (which was extremely late) was a change
<qu1j0t3> in fact i started on Mac XL -> Mac 512 and the first computer I bought myself was Mac Plus
<andlabs> it'd be nice if we had disk images that were specific for each model released
<qu1j0t3> those are probably archived somewhere
<andlabs> instead of just "random system 6 disks"
<andlabs> but eh
<qu1j0t3> the machine-specific ones were a pain in the ass really
<andlabs> I have an LC II, a SE/30, and a Classic II, all of which need to be recapped (and the SE/30 might have a bit more battery acid left on the board? we tried cleaning that out)
<andlabs> (amazingly the Classic II battery didn't leak)
<myon98> I noticed that a guide for m68k mac was recently published in JP (https://books.apple.com/jp/book/id6443016121) which deals with older systems too
<andlabs> I have a Performa 600 but IDK what the status is on that
<myon98> But my earliest experience with Macs is KanjiTalk (System) 7 on PPC, no 68ks unfortunately
<andlabs> and also a Power Mac 7100 and a ~ quoob ~
<andlabs> (both of which should work)
<qu1j0t3> actually the first MacOS i used was System 1.1
<qu1j0t3> but not sure i did any coding there
<qu1j0t3> i recall that for sure because it was Finder 1.1g
<qu1j0t3> my Inside Macintosh is the 1983 draft
<andlabs> cool
<andlabs> my mac experience started with educational AIOs
<andlabs> in schools
<andlabs> I don't know the pre-eMac models unfortunately
<andlabs> but I definitely used some
<andlabs> (mid-90s)
<qu1j0t3> the first coding tools i used were Macintosh Pascal (awesome) and Mac Development System .. i think Consulair thenbought by Apple. first C was Whitesmiths, then Aztec, Lightspeed, etc
<andlabs> aztec c? ah, amiga development on macintosh =p
<qu1j0t3> nah they had a Mac version :)
<andlabs> and cool, the mythical Whitesmiths compilers
<andlabs> (mythical to me, as a hardcore bell labs fan)
<andlabs> oh, I've found myself with two nextstations now too, a color and a turbo color
<andlabs> I have collected way too many computers
<andlabs> (still want to find the equally mythical Plan 9 Second Edition for NeXT)
<andlabs> oh someone's doing 9front on nexstation as a new port, neat
<fseidel> RE: the X68000, I've been able to develop for the thing with GCC 11.2.0, the codegen is generally pretty decent
<fseidel> AFAICT, the biggest issue is that the cost model was tuned around an '020 (with a few IF_68000_68010 checks in there)
<fseidel> but it's totally useable, and you'll get much better code than a crusty old C compiler from back in the day (like Sharp's, or a Human68K-native GCC 1.x)
<fseidel> you also have to deal with libc, I use a newlib port some guy put together about a decade ago, but it's kind of large and has some really janky string handling.
<andlabs> I still want to know what C compiler MNM Software used that generates 020 instructions in 000 mode, and whether those instructions will actually run in the game I found them in
<andlabs> unless they wrote it in assembly in which case woah
<fseidel> I assume you're talking about Slap Fight MD?
<andlabs> yes
<fseidel> you mentioned they were also using undocumented ops, right?
<fseidel> because that screams handwritten
<andlabs> we'll see whether Star Mobile has the same issue when that comes out
<andlabs> (A Ressha de Ikou MD seems to be an entirely different programmer)
<fseidel> https://twitter.com/MickyAlbert is the programmer, if you want to poke him :-)
<qu1j0t3> (gcc 1.x was pretty good on m68k ;-)
<NiGHTS> MickyAlbert (@MickyAlbert) / Twitter
<fseidel> qu1j0t3: the issue with 1.x is that it takes _forever_ running on a 16MHz 68000
* qu1j0t3 nods
<fseidel> the actual binaries it produces are generally okay
<qu1j0t3> when i used it i was probably already on 68030
<fseidel> one nice thing about a native Human68K toolchain is that you can use objects in Sharp's format, like their libc
<qu1j0t3> 1.37 fwiw -- as an MPW tool. it would handle programs larger than Apple's compieler could without crashing
<qu1j0t3> specifically, TeX and METAFONT
<qu1j0t3> idk who did that gcc port but it was a blessing
<fseidel> (I looked into trying convert their objects to ELF but it doesn't seem worth it, the linker format is insane)
<fseidel> there's a stack-based VM used to generate addresses, and it supports doing things I don't really know how you'd do in ELF
<andlabs> why are binary file formats so complicated
<fseidel> I went in assuming it would be dead simple (the executable format is), but nope, huge PITA
<cr1901> How to write a MOD player: Don't. How to write a Human68k obj file parser: Don't.
<fseidel> the guy who wrote CRS68K ended up writing a program to convert GAS syntax to HAS: https://github.com/yosshin4004/xdev68k
<NiGHTS> GitHub - yosshin4004/xdev68k: Cross development environment for the SHARP X68K.
<fseidel> he compiles with modern GCC, but assembles and links with the old native tools
<fseidel> this is actually a pretty decent solution
<qu1j0t3> nice.
<fseidel> there's also run68, which runs command-line Human68K programs on x86 Windows. Unfortunately, there's no Unix port :(
<fseidel> (some guy wrote one, but it also emulates sound hardware and has a bunch of Linux-specific stuff in there)
balrog has quit [Quit: Bye]
balrog has joined ##yamahasynths
<andlabs> oh yeah I was supposed to be writing a 68000 assembler too
<andlabs> god my brain rotted so much