2026-07-16 01:54:41 <xentrac     > veltas: game?
2026-07-16 07:29:02 <MrMobius    > I thought about having 5 copies of NEXT that execute round robbin then only check for interrupt in one of them
2026-07-16 07:29:45 <MrMobius    > to eliminate any overhead of checking
2026-07-16 07:29:53 <xentrac     > that's interesting
2026-07-16 07:30:24 <xentrac     > but I think what veltas was suggesting was not checking for interrupts in NEXT
2026-07-16 07:30:36 <xentrac     > oh, no, you're right
2026-07-16 07:31:11 <xentrac     > I was thinking that a hardware interrupt would overwrite NEXT with an interrupt vector jump to implement the software interrupt
2026-07-16 07:31:58 <xentrac     > but I think he was saying he couldn't use hardware interrupts
2026-07-16 07:47:41 <iv4nshm4k0v > AIUI, veltas wants to avoid using the hardware interrupt as that would interfere with video signal generation on the original ZX Spectrum 16K.  Not something that affects clones, or emulators, I think.  Or the use of the machine over a serial port.  (ISTR that one of the "Interface" extensions had one?)
2026-07-16 07:47:41 <iv4nshm4k0v > (There're kinda-sorta 128 possible interrupts in Z80 "IM 2" mode, but ZX Spectrum isn't designed to supply the interrupt number to CPU's data pins, so you get an arbitrary interrupt instead.)
2026-07-16 07:50:20 <iv4nshm4k0v > JFTR, the firmware has support for "channels," so "RST 8" (or whichever it is) doesn't necessarily write to screen - it can, essentially, pass the character (text?) to be written to an arbitrary output routine.
2026-07-16 07:55:44 <xentrac     > well, if it's a video signal timing thing, it's plausible that an "upper half" hardware interrupt handler that stores one to three bytes at NEXT would be fast enough
2026-07-16 07:56:43 <xentrac     > so the "lower half" would be executed later "in the background"
2026-07-16 07:57:12 <xentrac     > but I don't know enough about the Z80 in general and the ZX Spectrum in particular to know whether that makes sense
2026-07-16 07:57:31 <iv4nshm4k0v > It's not timing - it's that CPU tries to access RAM at the same time as the video output circuitry in the ULA.
2026-07-16 07:57:49 <iv4nshm4k0v > AIUI, anyway.
2026-07-16 08:03:14 <xentrac     > oh, so you get snow but not video signal timing errors
2026-07-16 08:03:36 <xentrac     > because it was the ZX81 that produced the video signal on the CPU itself
2026-07-16 08:03:53 <xentrac     > not the Speccy
2026-07-16 09:08:16 <veltas      > The FIFA world cup game between England and Argentina
2026-07-16 09:11:15 <veltas      > iv4nshm4k0v: Is there some way the channels can be used to add an interrupt handler or was that just an interesting sidetrack?
2026-07-16 09:12:30 <veltas      > MrMobius: How would you switch between the 5 versions of NEXT?
2026-07-16 09:17:47 <iv4nshm4k0v > Not that I know of, so sidetrack.  My point was that if you cannot use a hardware interrupt with the video circuits as they are - use a serial console.
2026-07-16 09:23:30 <veltas      > I see
2026-07-16 09:24:13 <veltas      > I'm trying to do this without extra hardware but I think what you're saying would have made sense in the 80's
2026-07-16 09:24:40 <veltas      > What's annoying about the channels is they weren't well designed, and with e.g. the microdrive I believe they changed format
2026-07-16 09:25:05 <veltas      > So it's just a complicated mess
2026-07-16 09:25:55 <veltas      > Sinclair really had no clue about software
2026-07-16 09:26:14 <veltas      > You get what you pay for, they were the cheapest option
2026-07-16 09:26:35 <veltas      > That makes it an interesting platform and an interesting challenge to work with though
2026-07-16 09:37:07 <iv4nshm4k0v > Wasn't the writing of the firmware outsourced, though?  My opense-basic/copyright mentions "Copyright: 1981 Nine Tiles Networks Ltd"; http://zxdesign.itch.io/opense might have more information on that.  Regardless, they haven't exactly got a chance to iron out the bugs in there.
2026-07-16 09:37:29 <xentrac     > yeah, the thing about hardware people is that, although they aree technically capable of writing software
2026-07-16 09:38:07 <xentrac     > the value system that produces good software runs counter to the value system that produces good hardware
2026-07-16 09:39:04 <xentrac     > so all their intuition about what is a good technical choice in a give context tends to lead them badly astray
2026-07-16 09:41:02 <veltas      > iv4nshm4k0v: Yes it was outsourced, but Nine Tiles weren't listened to
2026-07-16 09:41:37 <veltas      > For the original they suggested Forth because of how small it was, and Sinclair didn't listen.  For ZX Spectrum they wanted more time to fix performance issues and bugs but Sinclair wanted to ship as soon as possible, etc.
2026-07-16 09:42:17 <veltas      > The ROM included a way to let you write a custom NMI handler and they never tested it because there was no time, and it doesn't work.
2026-07-16 09:46:16 <veltas      > I think the issue here was Sinclair didn't really understand or appreciate the nature of software engineering
2026-07-16 09:46:22 <veltas      > It's amazing it worked as well as it did
2026-07-16 09:49:12 <xentrac     > yes, I think that's a common occurrence with hardware companies
2026-07-16 09:53:35 <veltas      > Nevertheless the Spectrum did have a pretty good CPU for its day, and was seriously cheaper than alternatives, and had slightly better options for storage than tape available too.  So it was actually okay for business and I know a lot of businesses used the ZX81 and ZX Spectrum.
2026-07-16 09:53:52 <veltas      > But this was in spite of the on-board ROM, rather than because of it
2026-07-16 09:54:44 <veltas      > When I started working the old guard had often cut their teeth writing Z80 machine code apps for businesses on ZX81 etc
2026-07-16 09:56:39 <veltas      > I definitely would have wanted a Spectrum if I was a kid in the 80's
2026-07-16 09:57:42 <xentrac     > I was, but I never heard of it until recently
2026-07-16 09:58:25 <veltas      > UK market
2026-07-16 09:59:41 <xentrac     > yeah
2026-07-16 09:59:53 <iv4nshm4k0v > ZX Spectrum clones were fairly popular in some countries - certainly USSR, also Uruguay, IIRC.
2026-07-16 10:00:34 <xentrac     > there was supposedly a popular ZX81 in the US: the Timex Sinclair ZX81
2026-07-16 10:01:17 <xentrac     > I read books about it at the time but never saw one as far as I can remember
2026-07-16 10:01:26 <veltas      > I know in a lot of Europe the Oric Atmos was really popular, and that's a fine machine
2026-07-16 10:01:37 <veltas      > A British computer but not that popular in Britain
2026-07-16 10:02:00 <veltas      > That is a pleasure to work on, but it's MS Basic so of course it is
2026-07-16 10:02:05 <xentrac     > did the Spectrum do NTSC?
2026-07-16 10:02:14 <veltas      > No
2026-07-16 10:02:24 <veltas      > Timex Sinclair would have done that
2026-07-16 10:02:38 <iv4nshm4k0v > I've got my clone c. 1992.  So far as I can tell, around here, such machines were used until early 2000s, at least as home computers.
2026-07-16 10:03:11 <xentrac     > you'd think NTSC color would be a little easier than PAL
2026-07-16 10:03:21 <veltas      > iv4nshm4k0v: Spectrum clone?
2026-07-16 10:03:30 <iv4nshm4k0v > Yes.
2026-07-16 10:03:34 <veltas      > xentrac: Why?
2026-07-16 10:04:44 <xentrac     > well, correct me if I'm wrong, but in PAL the chroma signal is sort of differential between lines
2026-07-16 10:04:54 <xentrac     > that's the
2026-07-16 10:05:03 <xentrac     > that's the "phase alternating" part
2026-07-16 10:05:37 <xentrac     > so the way you encode the chroma subcarrier depends on which line you're on?
2026-07-16 10:07:24 <veltas      > I guess that part is simpler but it's not exactly complicated either?
2026-07-16 10:08:21 <veltas      > Ultimately the video signal in spectrum was converted to PAL by a small separate unit, which is often bypassed now that it's easier to hook S-Video up than PAL
2026-07-16 10:09:07 <veltas      > I suspect the PAL part is actually on S-Video too but the box put it onto a TV channel?  Not 100% sure
2026-07-16 10:09:32 <veltas      > But you get a way better signal bypassing that box and just using direct s-video, obviously
2026-07-16 10:10:39 <xentrac     > huh, I didn't know that
2026-07-16 10:14:30 <iv4nshm4k0v > ISTR that S-Video has separate "brightness" (essentially, monochrome video) and "chroma" signals.  No idea if chroma is time-compressed there or not - but it needs to be squeezed into the horizontal blanking portions of the monochrome video to produce "composite" (?) video.  The latter is then shifted in frequency to one of the (analog) TV channels.  Or something.
2026-07-16 10:14:55 <veltas      > The video is generated by ULA and is mostly PAL when it comes out of there, and is adjusted and timed by some variable resistors before going to the magic box that encodes it like an aerial TV signal
2026-07-16 10:15:09 <veltas      > iv4nshm4k0v: That's the case with NTSC and PAL
2026-07-16 10:15:14 <veltas      > To support black & white TVs
2026-07-16 10:15:31 <iv4nshm4k0v > I'd think SECAM does that as well, no?
2026-07-16 10:15:38 <veltas      > Sure I just don't know SECAM
2026-07-16 10:15:55 <iv4nshm4k0v > Neither do I, I guess.
2026-07-16 10:17:50 <veltas      > I didn't know NTSC until I looked it up just now because xentrac said it was easier
2026-07-16 10:18:38 <xentrac     > chroma data is not transmitted during the horizontal blanking interval in any of NTSC, PAL, or SECAM
2026-07-16 10:19:07 <xentrac     > a "colorburst" to indicate the presence of the chroma data is
2026-07-16 10:24:49 <veltas      > Reminds me of how if signal was really bad the chroma would phases in and out, it would go black and white
2026-07-16 10:25:04 <veltas      > Presumably because the colorburst had too much distortion
2026-07-16 10:25:35 <veltas      > And you could tell when chrome had too much distortion because it would go crazy colours like purple etc
2026-07-16 10:25:44 <veltas      > and in a noisy way
2026-07-16 10:27:12 <xentrac     > yes
2026-07-16 10:27:45 <veltas      > I need to stop saying 'chrome' instead of 'chroma'
2026-07-16 10:27:55 <veltas      > I'm too used to typing 'chrome' obviously :)
2026-07-16 10:28:16 <xentrac     > it's a very interesting metal
2026-07-16 10:28:34 <veltas      > And yet the picture quality was better than it is today
2026-07-16 10:28:46 <veltas      > As netflix drip feed me bits over their wet string
2026-07-16 10:29:20 <xentrac     > chrome is hard enough to scratch quartz.  not many metals you can say that about
2026-07-16 10:29:53 <xentrac     > and of course its carbide is even harder
2026-07-16 10:30:50 <xentrac     > well.  or so I thought
2026-07-16 10:31:32 <veltas      > And yet it has no decent adblocker
2026-07-16 10:33:09 <xentrac     > oh, for that I use Firefox
2026-07-16 10:33:15 <xentrac     > my wife prefers Brave
2026-07-16 10:33:15 <veltas      > I will say adjusting the variable resistors on the ZX Spectrum issue 2 motherboard was a bit of a nightmare
2026-07-16 10:33:24 <veltas      > I also use Firefox
2026-07-16 10:33:32 <xentrac     > for the video signal?
2026-07-16 10:33:34 <veltas      > Yes
2026-07-16 10:33:54 <veltas      > A lot of tweaking and sweating with a screwdriver and hoping you don't drop it and short something
2026-07-16 10:34:26 <veltas      > And hoping the TV isn't trying to 'help' too much with the bad signal you're trying to correct so it looks good and then you reset the TV and it's bad again
2026-07-16 10:34:58 <veltas      > Which my Sony Trinitron CRT would do, surprisingly
2026-07-16 10:35:10 <veltas      > That TV was brilliant, I wish I could have kept it
2026-07-16 10:35:13 <xentrac     > huh
2026-07-16 10:35:53 <xentrac     > TVs that aren't brilliant can only be watched at night
2026-07-16 10:37:16 <iv4nshm4k0v > When we were making RF LC filters, we've made our screwdrivers out of toothpicks: the powdered iron cores were too fragile to use a conventional screwdriver on them.
2026-07-16 10:42:50 <iv4nshm4k0v > (Digital filters have a /huge/ advantage of not needing tuning, sure, but our specs required for the filters to reflect up to 100 W of interference back - not something that's all that easy to do with digital.)
2026-07-16 10:55:59 <veltas      > One day I'll learn electronics...
2026-07-16 10:56:24 <veltas      > I like the idea of creating an old school computer too
2026-07-16 10:56:34 <veltas      > Not sure what the right name for this syndrome is
2026-07-16 10:57:12 <lofty       > nostalgia
2026-07-16 11:00:50 <iv4nshm4k0v > Electronics is kinda big.  I've had some interest in electronics (thanks to older relatives, obviously) back in early 1990s, but it mostly waned as I've switched to programming.  Then I've discovered AVR MCUs c. 2005 - which kinda bridged the gap between (digital) electronics and programming for me.
2026-07-16 11:01:43 <veltas      > By 'learn' I mean learn the sort of 'basics'
2026-07-16 11:02:20 <veltas      > I'm good at reading modern digital schematics because I've just learned that for work, that's it
2026-07-16 11:10:48 <iv4nshm4k0v > The basics are: U = IR (Ohm's law), P = I^2 R (Joule's law), Q = CU for capacitors, and the respective (due to duality) equation for inductors.  IME you can go a very long way with electronics on Ohm's law alone.  (And the observation that charge does not accumulate in circuit's nodes - so the sum of currents flowing into one equals the sum of currents flowing out.)
2026-07-16 11:23:51 <MrMobius    > veltas: NEXT1 would be hard coded to jump to NEXT2 etc
2026-07-16 11:27:10 <iv4nshm4k0v > NEXT is supposed to be called at the end of (almost) every Forth word.  I don't see how it could be easily arranged so a different actual routine is called every time the code calls (or jumps to) NEXT.
2026-07-16 11:29:34 <MrMobius    > sorry, that's not very helpful how I said it. if you have a dispatcher, you might have five copies of the dispatch code and check every 5th time through
2026-07-16 11:30:07 <MrMobius    > yes, if you load and jump the next word at the end of each primitive, there's not much you can do
2026-07-16 11:34:38 <MrMobius    > unless you want multiple copies of the primitives where each jumps to the next set at the end of the word but then you'd need to calculate a target address each time which might not be a win
2026-07-16 11:40:55 <veltas      > So it's more like if you return to the 'dispatcher' after a word then you can have different NEXT's inline and the first/last one can call the interrupt?
2026-07-16 11:42:51 <veltas      > This is similar to how ilo works because it has an instruction loop that reads the operation word and then updates IP but shifts through that initially read word for 4 executions, even if IP moves
2026-07-16 11:43:12 <veltas      > In ilo you might put that interrupt at the start of each word read
2026-07-16 11:50:25 <veltas      > Because that is followed by 4 executions
2026-07-16 22:55:06 <cleobuline  > https://labynet.fr/videos/mandelbrot.mp4