2026-09-15 00:20:00 <xentrac     > yes, you do have to clip the line for that kind of thing; it may be adequate to round the resulting new line endpoints on the screen boundary to integers, especially if you're drawing something that's moving fast
2026-09-15 00:29:32 <xentrac     > that rounding does generate some janky jitter, especially on a low-resolution display like the Spectrum's, but in fast-moving scenes, that averages out
2026-09-15 09:01:47 <veltas      > xentrac: Presently I'm not going to handle fractional start/end coordinates on basis that it's an 80's computer so jank seems reasonable
2026-09-15 09:02:19 <veltas      > But I have seen people do that and it looks awesome
2026-09-15 09:03:08 <veltas      > With bresenhams I think I just need to calculate the start error value to make it fractional, so it's something that can be easily patched in I think
2026-09-15 09:05:27 <veltas      > After muddling with the weird screen coordinate calculations I think I'm going to shelve what I've got and start again with a simple layout bitmap as a separate drawing buffer
2026-09-15 09:05:45 <veltas      > And I think I'll optimise drawing to the top two thirds, similar to elite yeah
2026-09-15 09:21:07 <veltas      > Always surprising to me what's faster on Z80, e.g. I want to add 0x20 to a 16-bit value in HL.  It's faster to move the low part to A and add it and then check if there's a carry before INC H than just setting e.g. DE to 0x0020 and adding it to HL in a 16-bit add
2026-09-15 09:22:02 <veltas      > Rather... it's faster without the carry.  So if the carry is likely then do the 16-bit add, but if it's equally distributed it's significantly faster to do it all 8-bit
2026-09-15 09:37:06 <iv4nshm4k0v > Z80 is a 8-bit CPU.  I guess that's why 8088 caught like fire - it offered a considerable imporvement in performance, especially when 16-bit (or wider) arithmetics was needed.
2026-09-15 09:41:36 <veltas      > With a 4-bit ALU
2026-09-15 09:43:01 <veltas      > Yeah I'm not unaware it's an 8-bit CPU, but just surprised at the number of extra 8-bit ops I can do without being slower than 2 (of the faster) 16-bit ops
2026-09-15 09:44:13 <veltas      > I almost managed to use the parity flag last night trying to optimise something... but the whole direction I went turned out to be a dud
2026-09-15 11:01:39 <MrMobius    > might as well switch to the much superior 6502 at that point :P
2026-09-15 11:15:14 <veltas      > 
ACTION chases MrMobius around the room with a rubber chicken

2026-09-15 12:35:07 <xentrac     > having a 16-bit data path doesn't necessarily automatically grant you improved performance, but it does help.  also the "HMOS" 8088-2 could run at 8 MHz, while the Z80A was limited to 4MHz.  both eventually got versions you could clock much faster, up to 16MHz for the 8088 and 20MHz for the Z80
2026-09-15 12:40:14 <xentrac     > they still make the eZ80, and those run at 50MHz, quite a bit faster than a 16MHz 8088
2026-09-15 12:41:47 <xentrac     > but I think cutting clocks per instruction from ≈6 on the 8088 down to ≈1.1 on RISC designs made a bigger difference than widening the data path to 32 bits
2026-09-15 12:44:27 <xentrac     > the 6502 could execute a lot of instructions in 2 external clocks, but in a sense that's because it had a two-phase internal clock, so it was still internally more like an average of 5 clocks per instruction ("5T")
2026-09-15 12:46:00 <xentrac     > Moore's MISC designs were an alternative path to the RISC approach, trying to further reduce the work per instruction so you could eliminate the RISC pipelining as well
2026-09-15 12:47:12 <veltas      > MrMobius and I have already endlessly debated the whole 6502 vs Z80 question
2026-09-15 12:47:27 <xentrac     > but the cost was that you needed to execute more instructions to do a task, which was anticipated to be a drawback of RISC but didn't turn out to be in practice
2026-09-15 12:47:44 <xentrac     > yes, you and millions of other people
2026-09-15 12:48:05 <MrMobius    > 
ACTION reduces the frequency of veltas' rubber chicken by 50%

2026-09-15 12:48:11 <xentrac     > I frequented C64 BBSes in my childhood and I think people were debating it then
2026-09-15 12:49:19 <veltas      > More recently people have had arguments about RISC-V in here
2026-09-15 12:49:34 <veltas      > So I guess RISC-V allows us to continue fighting about mostly-pointless things
2026-09-15 12:49:39 <MrMobius    > hehe
2026-09-15 12:49:57 <xentrac     > right.  ultimately RISC, OoO micro-op decoded designs, and GPUs won
2026-09-15 12:50:18 <MrMobius    > I usually learn something so not entirely pointless. I think you pointed me to a report showing better code density on Z80 last time we talked about this
2026-09-15 12:50:29 <xentrac     > I should mention superscalar
2026-09-15 12:50:53 <veltas      > Well 8-bit is a bit pointless now either way, although that's not stopped me enjoying and writing 8-bit code the last few days
2026-09-15 12:50:57 <xentrac     > I think RVC and Thumb are generally the champions for code density
2026-09-15 12:51:13 <veltas      > I do a lot of pointless things, the main thing is nobody gets hurt :P
2026-09-15 12:51:34 <xentrac     > I don't think it's pointless; even today there are a lot of 8-bit microcontrollers being sold
2026-09-15 12:51:53 <xentrac     > but a lot of them are AVR, which is a RISC design
2026-09-15 12:52:07 <MrMobius    > I'm kind of confused why anyone cares about RISC-V from a tech point of view. It's a slightly improved MIPS which we've had for almost 40 years. PIC microcontrollers with MIPS have been out for 12 years.
2026-09-15 12:52:39 <MrMobius    > 8 bit is just fun in a different way
2026-09-15 12:53:07 <xentrac     > well, RVC does have better code density than MIPS (even MIPS16) and sometimes even Thumb
2026-09-15 12:53:20 <xentrac     > the top two microcontrollers in Digi-Key's stock are 8-bit chips: https://www.digikey.com/en/products/filter/embedded/microcontrollers/685?s=N4IgjCBcoLQExVAYygFwE4FcCmAaEA9lANogCsIAugL74wCciIKkGO%2BRkpENtIAbEwCWAEyggYYAAwJ8AB1TiQ%2BVAE852cSIDOKatSA
2026-09-15 12:53:40 <MrMobius    > I've made a few versions of an 8051 board that I'm going to make into a calculator. Feels a little like 6502 but much easier circuit since your have boot ROM and peiperheals built in but can optionally add external ram and rom
2026-09-15 12:54:07 <xentrac     > the top one is actually a 50Mhz Silicon Labs 8051, followed by an AVR ATTiny13A
2026-09-15 12:55:20 <MrMobius    > hehe 8051 ftw
2026-09-15 12:55:25 <xentrac     > followed by a 32-bit ARM, an 8-bit PIC10F, and a RasPi 32-bit ARM (SC0914(13), which I haven't heard of)
2026-09-15 12:55:33 <MrMobius    > they have been declaring that thing dead for years but they just won't stop making them
2026-09-15 12:56:00 <xentrac     > oh, it says "dual-core", so maybe that's one of the ones that also has a RISC-V core
2026-09-15 12:57:10 <xentrac     > then we get into chips of which Digi-Key has less than 100,000 in stock
2026-09-15 12:58:06 <xentrac     > but out of those top 5, 3 are RISC (and 2 are 32-bit RISC), and 3 are 8-bit
2026-09-15 12:59:19 <xentrac     > which suggests that 8-bit is not pointless at all.  Despite Digi-Key's hobbyist roots, I don't think they have half a million 20-QFN EFM8BB21F16I-C-QFN20Rs in stock to serve hobbyists
2026-09-15 12:59:40 <veltas      > RISC and RISC-like is better design, the nasty non-RISC stuff is usually there because it's backwards-compatible with something
2026-09-15 12:59:45 <xentrac     > the hobbyists would mostly prefer QFPs to QFNs, and there aren't that many of them
2026-09-15 13:00:06 <xentrac     > I don't know, I think RISC approaches are situational
2026-09-15 13:00:49 <veltas      > Most of the CPU's I've worked with are not RISC, but in my day job now it's mostly ARM so I guess RISC.  It doesn't matter to me at all really.
2026-09-15 13:01:17 <veltas      > I tend to prefer specs and docs for RISC platforms, they tend to be better written
2026-09-15 13:01:22 <xentrac     > for RISC to make sense, you need enough transistors per thread that you can afford to pipeline, but not so many transistors per core that you can afford to decode instructions into separately dispatchable micro-ops
2026-09-15 13:01:30 <veltas      > Although I don't feel that way about RISC-V
2026-09-15 13:02:23 <xentrac     > I like the RISC-V unprivileged ISA spec; it's the only one I've seen that really provides justifications for their design decisions
2026-09-15 13:02:52 <xentrac     > but I agree that its literary quality is not up to the early SPARC or ARM manuals
2026-09-15 13:04:16 <MrMobius    > RISC is less nice if you have to write assembly
2026-09-15 13:05:03 <MrMobius    > I like doing `mov eax, [ebx+ecx*4+500]` better than the MIPS/RISC-V equivalent
2026-09-15 13:05:27 <MrMobius    > but hardly anyone writes assembly
2026-09-15 13:06:25 <xentrac     > oh, I think ARM is nicer than i386 for writing assembly
2026-09-15 13:06:25 <veltas      > I actually enjoy writing RISC and 6502 assembly
2026-09-15 13:07:35 <veltas      > Took me a while to understand how x86 memory references work and what you can encode
2026-09-15 13:07:41 <veltas      > And I still don't fully understand it
2026-09-15 13:08:01 <xentrac     > I mean on ARM you can `ldr r3, [r0, r2, lsl 2]`, which is the equivalent of `mov eax, [ebx+ecx*4]`
2026-09-15 13:08:56 <xentrac     > you just don't get the +500.  but as a bonus you do get conditional execution (`ldrge`) and post-increment
2026-09-15 13:10:09 <xentrac     > and it executes with a latency of one cycle on most ARMs, and caring about that kind of thing is normally why you're writing assembly in the first place
2026-09-15 13:11:46 <MrMobius    > that's cool
2026-09-15 13:11:59 <MrMobius    > but ARM is not RISC any more at that point :P
2026-09-15 13:12:27 <xentrac     > most RISCs don't go quite as far as ARM with their addressing modes, it's true
2026-09-15 13:12:29 <MrMobius    > not that the strict classification matters that much
2026-09-15 13:12:59 <xentrac     > but it does seem to have taken the parts of RISC that mattered most at the time
2026-09-15 13:13:36 <xentrac     > arguably ldm/stm/push/pop are less RISCy than the above though
2026-09-15 13:14:23 <xentrac     > well, it's not really arguable.  they definitely are
2026-09-15 13:19:07 <xentrac     > RISC-V is pretty ideologically pure as RISC, and it's a bit more of a drag to write code for as a result
2026-09-15 13:45:31 <iv4nshm4k0v > FWIW, I had trouble understanding how C works on AVR, so my first programs there were in assembly.  Settled on ATtiny13A as my preferred "tiny" MCU before long, too.
2026-09-15 13:50:50 <xentrac     > it's a pretty neat little chip
2026-09-15 13:51:08 <xentrac     > what have you been doing with it?  do you have a Forth running on it?
2026-09-15 13:59:00 <cleobuline  > next , i will   do a forth emulator with hypertalk :)
2026-09-15 13:59:42 <cleobuline  > when i finish my HC  thing xentrac
2026-09-15 14:06:02 <xentrac     > that sounds like fun!  I don't know what Hypertalk's facilities for structuring data are
2026-09-15 14:07:13 <iv4nshm4k0v > I doubt I've as much as seen a Forth implementation for anything that small.  As to uses, one of my first programs was one to play several measures of Beethoven's Piano Sonata No. 14 - mixing something like 5 channels (sine wave approximation) to a PWM output.  Mostly, I've been using it to produce various test signals, like SPI commands to devices.
2026-09-15 14:13:00 <xentrac     > you might enjoy trying out Karplus-Strong synthesis on it; it has 64 bytes of RAM, which is enough to dedicate 16 bytes to a delay line that can produce a 16-harmonic approximation of a guitar
2026-09-15 14:13:34 <xentrac     > in theory you can use Karplus-Strong to do a piano too, but I haven't managed it
2026-09-15 14:15:56 <cleobuline  > https://ibb.co/5hyrBxZr  my hc thing
2026-09-15 14:18:58 <xentrac     > it looks good
2026-09-15 14:33:17 <xentrac     > you can probably do quite a bit of FM synthesis on that chip too; by varying the depth of modulation you can get a decay-toward-sinewave effect that's interestingly similar to how the higher harmonics decay faster in Karplus-Strong
2026-09-15 15:30:44 <iv4nshm4k0v > That's 16 bytes per channel, I presume?  IIRC, Sonata No. 14 will need at least three independent channels, so it gets pretty tight.  I've been thinking of implementing FM synthesis there, but so far, other things took priority.
2026-09-15 15:32:34 <xentrac     > right, 16 bytes per Karplus-Strong channel.  you could get by with less, maybe as little as 4, at the cost of supporting less harmonics
2026-09-15 15:35:02 <xentrac     > I think K-S is normally explained with a positive comb filter and lowpass y(n) = (y(n-k) + y(n-k-1))/2 which gives you both even and odd harmonics, but making the comb filter negative y(n) = -(y(n-k) + y(n-k-1))/2 gives you only odd harmonics and allows you to use a delay line that's half the size
2026-09-15 15:40:34 <xentrac     > I was thinking you might be able to use less-memory-hungry approaches like FM synthesis for everything that isn't the lead melody.  Moonlight Sonata has a pretty well defined lead melody, but its arpeggios really benefit from its notes overlapping
2026-09-15 15:43:24 <iv4nshm4k0v > Yeah; reading http://en.wikipedia.org/wiki/Moonlight_Sonata#Beethoven's_pedal_mark right now.  Curiously enough, while "The modern piano has a much longer sustain time than the instruments of Beethoven's time," the electronic pianos (at least the simpler ones I've had a bit of experience with) do not share that characteristic.
2026-09-15 15:44:16 <xentrac     > I think you really need 5 channels for it
2026-09-15 15:45:37 <iv4nshm4k0v > Two notes an octave apart sound much like a single note, though louder and with a different timbre.  That may allow to save one channel.
2026-09-15 15:46:10 <xentrac     > 6 would be better
2026-09-15 15:46:36 <xentrac     > yes, it does do that octave thing a lot
2026-09-15 15:47:00 <xentrac     > but the bass accompaniment, if that's the term, isn't *always* an octave interval
2026-09-15 15:48:34 <xentrac     > it shifts in and out of the octave
2026-09-15 15:55:27 <xentrac     > near the end, I'd forgotten this, but there are sections with as many as eight notes sounded at once.  which you could probably cheat a bit on
2026-09-15 15:55:31 <xentrac     > but for example https://youtu.be/4591dCHe_sE?list=RD4591dCHe_sE&t=761
2026-09-15 15:56:57 <xentrac     > it might be hard to do more than several measures without an external I²C Flash chip or something to store them in
2026-09-15 16:02:58 <xentrac     > I wonder if Beethoven ever hated the Moonlight Sonata.  He wrote it when he was 31, and although he wrote many other wonderful pieces in the remaining 26 years of his life, I don't think anything else quite measures up, not even the Fifth Symphony and the Ninth Symphony
2026-09-15 16:05:30 <iv4nshm4k0v > Interfacing external flash would take up program flash and cycles, both limited as they are.  (E. g., my code would support up to 8 channels, but trying to play more than five or so at the same time would run out of cycles.)  But as I only did a few measures at the start of 1st movement, I didn't need to concern myself with the complexity of the latter parts of the piece.
2026-09-15 16:10:02 <iv4nshm4k0v > I frankly doubt that it makes much sense to compare symphonies to sonatas.  I can certainly appreciate Moonlight /and/ Ninth, each in its own way.  (Much like how I can appreciate Master Boot Record referencing Beethoven works in those of his own.)
2026-09-15 16:52:38 <xentrac     > vdupras: have you checked out comp.lang.forth recently?
2026-09-15 16:53:28 <vdupras     > xentrac: no, should I?
2026-09-15 16:58:05 <xentrac     > there are some pretty competent Forth programmers posting there, and Usenet seems to be almost entirely free of spam nowadays
2026-09-15 16:58:10 <xentrac     > so you might enjoy it
2026-09-15 16:59:12 <xentrac     > Anton Ertl, Albert van der Horst, Hans Bezemer, Marcel Hendrix, Terry Porter, and a few others
2026-09-15 17:03:05 <xentrac     > oh, and Stephen Pelc
2026-09-15 17:04:16 <xentrac     > you'd have a lot to contribute
2026-09-15 17:06:37 <crc         > 
ACTION hasn't looked at c.l.f in several years

2026-09-15 17:07:06 <vdupras     > maybe it's a good idea. I've never been on usenet, maybe it's worth exploring
2026-09-15 17:07:47 <crc         > I'd assume the spam went down after google killed groups; it was really bad for a while
2026-09-15 17:09:03 <crc         > Looks like narkive still works for read-only access; https://comp.lang.forth.narkive.com/
2026-09-15 17:10:31 <xentrac     > vdupras: there's a certain amount of flaming, but there's also a lot of high-quality knowledge flying around
2026-09-15 17:11:49 <xentrac     > for example, on https://comp.lang.forth.narkive.com/aQ3Kyxhu/dynamic-scoping-in-forth-in-one-line-of-code dxf helpfully explained to me that the dynamic-scoping trick I talked about here was already known
2026-09-15 18:24:58 <iv4nshm4k0v > CLF is one of the "better" comp.* groups these days, IMO: it has a healthy amount of activity, participants who /know/ what they're talking about, /and/ it's reasonably focused.  There's, say, comp.unix.shell, but its activity is sporadic at best; or comp.misc, but (as to be expected) it's not particularly focused.
2026-09-15 19:14:31 <xentrac     > I've also enjoyed comp.lang.misc, comp.arch, alt.usage.english, and a few others
2026-09-15 19:14:47 <xentrac     > > participants who /know/ what they're talking about,
2026-09-15 19:15:03 <xentrac     > well, there are some, but I also participate in comp.lang.forth myself
2026-09-15 19:22:00 <anthk_      > comp.misc too
2026-09-15 19:22:24 <anthk_      > ah, already mentioned
2026-09-15 19:22:37 <anthk_      > and comp.lang.lisp, from the other side of the mirror ;)
2026-09-15 19:23:10 <xentrac     > yeah, there's some good stuff there for sure
2026-09-15 21:14:37 <veltas      > There is an invisible force that stops me from entering those communities
2026-09-15 21:17:24 <bjorkintosh > veltas: where, lisp?
2026-09-15 21:17:28 <bjorkintosh > we love company
2026-09-15 21:22:48 <veltas      > No comp.lang.forth, Forth200x stuff, the Forth 2020 Facebook etc
2026-09-15 21:23:14 <veltas      > The Forth GitHub group, I could go on...
2026-09-15 21:23:40 <veltas      > I'm too dumb to write lisp, at least that's the impression I get from my limited exposure to it
2026-09-15 21:24:41 <veltas      > I'd like to learn Guile or something but it's probably not going to happen
2026-09-15 21:44:48 <crc         > apart from trolls & spam issues; comp.lang.forth always felt too ANS-focused for me
2026-09-15 22:41:09 <xentrac     > people there seem to be largely discussing their own Forth dialects at this point.  in the case of Anton Ertl that's GForth, but Stephen Pelc mostly talks about VFX Forth, Terry Porter mostly talks about Mecrisp (though he didn't write it), Albert mostly talks about ciforth, etc.
2026-09-15 22:41:22 <xentrac     > Hans Bezemer mostly talks about his own Forth but I forget what it's called
2026-09-15 22:41:37 <lowtechloskop> 4th
2026-09-15 22:42:04 <xentrac     > right, 4tH, sorry
2026-09-15 22:42:23 <lowtechloskop> i think it's intended to be a compiled language at its core, iirc