<whitequark[cis]>
i don't have an objection to dockerfile using nix other than "i think i want the entire reproducible build recipe to live in a single file"
<whitequark[cis]>
if i have to include weird distro-specific instructions for how to obtain the nix executables i do not want nix
<whitequark[cis]>
(well, on the top level)
<SnoopJ>
whitequark[cis], the way I do it is with an additional `thing-docker` target that does `docker run --volume /host/pth/Makefile:/guest/pth/Makefile --entrypoint make --workdir /guest/pth/ -t someimage:1.2.3 thing` (roughly)
<SnoopJ>
in other words: I let the Makefile drive Docker as well
<whitequark[cis]>
the firmware build process is extremely streamlined so there's no real benefit to using the massive nix hammer on it
<tpw_rules>
i guess you'd just need to make sure you pin the docker base image tag and sdcc binary
<whitequark[cis]>
--volume Makefile --entrypoint make is cursed
<SnoopJ>
ye
<SnoopJ>
you could do `docker run … make -F …` if you want but I have trust issues
<whitequark[cis]>
tpw_rules: yes, exactly. it would be a specific Debian or whatever base image and a specific sdcc version
<whitequark[cis]>
there isn't any material benefit in using nix on top
<SnoopJ>
(and also 80% of my effort on this project is being careful not to step on the beartraps the moron who built it left behind)
<tpw_rules>
that's just a lot more massive on my disk space. but i don't want to argue, i can toy and maybe submit a PR down the line. i don't know enough to write a dockerfile myself though
<whitequark[cis]>
actually, does nix leave old derivations around forever?
<tpw_rules>
until you garbage collect them
<whitequark[cis]>
no, i mean, like, in nixpkgs or something
<whitequark[cis]>
will i ever encounter a situation where the firmware is built against sdcc 4.0.0 and that's no longer available in nixpkgs?
<ar>
i don't think hydra's cache is ever pruned
<tpw_rules>
the textfiles yes. the stuff it downloads i think rumor has been that it may need to happen soon, deleting very old things
<whitequark[cis]>
the word "cache" in this context makes me uncomfortable
<ar>
and you can pin your nixpkgs version down to specific commit
<whitequark[cis]>
ok but presumably eventually the nix binaries break compatibility badly enough that old nixpkgs are no longer usable
<tpw_rules>
it's called a cache because theoretically everything in it is bit reproducible
<tpw_rules>
i don't think that's happened yet either
<SnoopJ>
I think her question is: can you always get back that configuration even when you have nothing at all cached (assuming the upstream store still exists)
<tpw_rules>
yes
<ar>
whitequark[cis]: there have been situations where a given version of Nix is too old for newer nixpkgs, but don't remember the reverse happening
<ar>
and i did need recently to build something on my nixos-unstable laptop using nixpkgs from late 2019
<tpw_rules>
so far the only rot i've encountered is when third party upstream sources disappear
<tpw_rules>
(which does not happen for stuff in nixpkgs because the CI caches those too)
<whitequark[cis]>
re disk space, i looked at alpine but that does not have sdcc
esden[cis] has quit [Quit: Idle timeout reached: 172800s]
<tpw_rules>
the sdcc people publish binaries of some kind, i kind of suspected you would use them? idk about the libc difference though, that may not work
<whitequark[cis]>
debian's bookworm-slim image is 74 MB in size
<whitequark[cis]>
is that too much?
<tpw_rules>
ah, i wouldn't say so
<ar>
re: disk space: on my laptop and server, where i occasionally build full configurations for 4 different machines and disk/sd images for another two, x86_64 and aarch64, "nix-collect-garbage -d" removing around 100GB isn't uncommon
<whitequark[cis]>
sdcc binaries link to glibx
<whitequark[cis]>
s/glibx/glibc/
<ar>
(though the disk/sd images are the bulk of it recently, really; around 4-5G each)
<whitequark[cis]>
yeah it sounds odd to hear a nix user complain about wasted disk space >.>
<whitequark[cis]>
anyway, i guess a specific debian tag + dockerfile should do the trick
<tpw_rules>
i think i have to interact with too many docker images which install like a full ubuntu each time
<whitequark[cis]>
ah
<tpw_rules>
you'd have to get the sdcc binaries from sourceforge too?
<whitequark[cis]>
debian includes a perfectly serviceable sdcc binary
<tpw_rules>
how do you pin it?
<whitequark[cis]>
well
<tpw_rules>
iirc it's possible with apt but bizarre
<whitequark[cis]>
it's never actually updated within a release
<SnoopJ>
using a workflow organized around Debian images sounds like it has fewer sharp edges. can always change your mind later, too
<tpw_rules>
yeah i don't disagree. i think i'm falsely equating ubuntu again too
<whitequark[cis]>
there's security updates and backports but i don't think anyone does any of those for sdcc
<whitequark[cis]>
cursed option: just compile all of sdcc to wasm, and push it to pypi (no)
<SnoopJ>
tpw_rules, you can tell apt exactly what version of a package you want (i.e. `apt install pkg=X.Y.Z`) but I'm not sure what the workflow is for "pinning" especially in the context of an entire build like this
<tpw_rules>
apparently it's happened in the past
<SnoopJ>
you can definitely interact with the "policy" for packages but I don't know if there's an equivalent of like `requirements.txt`
<whitequark[cis]>
SnoopJ: it's literally two packages (sdcc and sdcc-libraries) so you can specify the version of both directly
<whitequark[cis]>
tpw_rules: oh, did it?
<SnoopJ>
whitequark[cis], ah, then yea no fuss
<whitequark[cis]>
like the firmware is not complex, the build process is not complex, the dependencies are very few (git, make, sdcc; not even gcc is needed)
<tpw_rules>
there's a dfsg-2
<whitequark[cis]>
* Add build dependency on texlive-latex-extra (Closing #917692)
<whitequark[cis]>
* Bump standards version to 4.3.0, no changes needed
<SnoopJ>
whitequark[cis], I think a docker image is a reasonable way to do it, especially if you're willing to keep your own stash of the image locally just in case
<whitequark[cis]>
from 3.8.0+dfsg-1:
<whitequark[cis]>
what.
<whitequark[cis]>
* Add dependency on inkscape (Closes: #911713)
<whitequark[cis]>
note that buster is oldstable or sth
<whitequark[cis]>
oh, oldoldstable even
<whitequark[cis]>
time flies
<tpw_rules>
i think it's for building the package itself ojnly
<tpw_rules>
oh damn sdcc has 6502 support now?
<whitequark[cis]>
for a while iirc
<tpw_rules>
i wonder if it's better than the depressing cc65
<whitequark[cis]>
Planned backends for SDCC 4.5.0
<whitequark[cis]>
Together with a partial rewrite of the mcs51 backend (switching to the new register allocator), support for the three most-common dual-dptr schemes shall be introduced.
<whitequark[cis]>
oh damn
<whitequark[cis]>
holy shit
<whitequark[cis]>
that would potentially considerably improve and/or break our firmware
<tpw_rules>
i have not heard good things about sdcc and 8051 but i don't think we want to splurge out for a keil license...
<whitequark[cis]>
i mean we are heavily using sdcc and 8051
<tpw_rules>
better than learning 8051 assembly though
<whitequark[cis]>
in the glasgow
<whitequark[cis]>
(and also 8051 assembly at places)
<tpw_rules>
yeah i recognize that, i'm just saying it's known to not be efficient
<tpw_rules>
(to me)
<whitequark[cis]>
it's perfectly serviceable. some tuning is required to compensate for the most batshit codegen decisions
<whitequark[cis]>
the main thing impairing it is the total lack of inlining (not specific to 8051)
<chipb>
8051 ;_;
brolin has quit [Ping timeout: 245 seconds]
<jwise0[m]>
I assume it is the classic micro-embedded C thing: you do non performance critical stuff in the high level compiled language, and any time you care to do anything in much of a hurry, or recur deeply in a way that will eat up all five bytes of stack space you have or whatever, you write some asm
<jwise0[m]>
that is pretty good if you can get the endpoints all the way over to the I/O ports efficiently enough otherwise. I assume that the Cypress folks decided to do things like 'actually designing their chip to require little CPU intervention' or something, though
<chipb>
I'm just reminded of my intro to embedded systems course in university. "Gods this thing is limited. I mean, it works, but...can't we use *anything* else?" "No, it's pretty industry standard they're going to be around for a loooong time."
<chipb>
...and this was 20ish years ago.
<whitequark[cis]>
jwise0: the general FPGA comms happen without the 8051 being involved at all
<jwise0[m]>
having never used one of these parts myself, I went to look to see what pricing is like, and ... interesting price breaks. it seems like there is some arbitrage available here
<whitequark[cis]>
considering that this thing is one of the most reliable and widely used ASICs in the entire history of computing, designing one in is rarely a mistake
<whitequark[cis]>
and it has proved to work flawlessly in Glasgow
<whitequark[cis]>
that's it. that's the erratum. sole thing discovered in almost 25 years of it being available
<jwise0[m]>
yeah, I just came back to this tab after having finished looking on my own (welp). looks like Digikey will actually sell you a CY7C68013A-56LTXCT, qty1k, for $7.55, byo 256kbit i2c EEPROM ($0.23). I assume somebody will sell you a flash micro for cheaper but that seems like $7.78 of good spending to meaningfully reduce design risk
<whitequark[cis]>
it's not it being a flash micro that's the point
<whitequark[cis]>
it's the 336 Mbps of data it can pipe to your FPGA straight from USB, with zero risk
<josuah>
where is the impression fo FX2 being so broadly used from? Any hints for some rookie?
<whitequark[cis]>
everything else about the FX2 is utterly forgettable and in some cases bad (no UART in the 56-pin packages? wtf)
<whitequark[cis]>
josuah: basically any time you have a cheap device that is "USB plus something not USB capable" it will use the FX2
<whitequark[cis]>
the FX1 and then FX2 were developed at a time when microcontrollers with USB were not a thing, and they capitalized heavily on it
<tpw_rules>
(in my experience it will use an FTDI part...)
<whitequark[cis]>
right, I should be more specific
<josuah>
maybe a few very specific cases are going to have full-custom asics, like pendrives or mouses or keyboards
<whitequark[cis]>
it's FTDI if it's roughly USB serial shaped, and it's FX2 if it's roughly USB parallel shaped
<chipb>
josuah: I've got handfuls of devices relying on them in my office cube alone -- it's the core chip in the Altera USB Blaster II pod.
<whitequark[cis]>
like, all the USB ATA stuff used to use FX2 for a while
<josuah>
that's still a lot of devices
<chipb>
or whatever Intel renamed it to.
<josuah>
are FTDI capable of arbitrary USB descriptors an protocols and whatnot? maybe I know the family not well enough
<jwise0[m]>
yeah, I mean to say, you can often make what you need out of a flash micro, at higher engineering cost and risk, but ...
<whitequark[cis]>
josuah: no, but you can set vid/pid
<jwise0[m]>
FTDI can have semi-arbitrary descriptors / strings iirc, but you are basically writing your own drivers on the host side to make the FTDI side do what you want, rather than emulating any particular class
<whitequark[cis]>
most of these devices don't really make use of arbitrary USB descriptors though, even though some do, and quite effectively
<jwise0[m]>
(is USB MSC designed in such a way that 'DMA engine go brr' can be used to drive an ATA interface with it?)
<whitequark[cis]>
i think this especially applies to ATAPI
<whitequark[cis]>
where the FX2 can pipe your commands to the CD-ROM almost entirely directly
<whitequark[cis]>
for ATA there would be more work involved for the 8051
<jwise0[m]>
I should read the datasheet for one of these things. the FX2 sounds like a 'believe in what is possible' class of device
<whitequark[cis]>
it's fantastic
<jwise0[m]>
(to the extent that I have quite some antipathy for RP2040 as a part in general, I grudgingly appreciate the 'believe in what is possible' nature of the PIO peripheral.)
<whitequark[cis]>
oh, why do you dislike it?
<jwise0[m]>
early errata were sort of miserable ('USB requires stuff tied externally in order to work right'); CM0 instead of CM3 seems like an unnecessary handicap to the chip (I would probably rather one CM4F than two CM0 for most things? but I assume this is potentially related to ARM DesignStart licensing); the part is astonishingly poorly characterized (datasheet info on power consumption, last I looked, was 'we tried this particular test
<jwise0[m]>
program on three individual parts', rather than characterization across silicon corners or any such), which makes me very nervous about designing it in for anything that will run in any condition other than 25C for 1 year; also power consumption in low power states is best described as 'lol' (static Vddio current > 1 mA???)
<whitequark[cis]>
wtf
<whitequark[cis]>
yeah ok i see it is very babby's first asic
<whitequark[cis]>
two CM0 are i think homage to Propeller
<SnoopJ>
> 1 mA is "low power?" o.O
<tpw_rules>
i need to do something with Propeller again
<SnoopJ>
first bullet point reminds me of what rpi started as rather than what it turned into
<SnoopJ>
last point has me just thinking about the supercon 2023 badge which looks very neato
brolin has quit [Ping timeout: 248 seconds]
<whitequark[cis]>
was rpi ever cheap as dirt
<whitequark[cis]>
(without brcm subsidy)
<SnoopJ>
oh huh I didn't realize they subsidized. If they did that in the very early days, I guess not?
<SnoopJ>
I guess for the original goal of "put cheap computers in student hands" I don't actually care about the subsidy, but I take your meaning
<whitequark[cis]>
well broadcom had a stock of worthless socs using an ancient core so bad not even soho router vendors wanted it
<whitequark[cis]>
SnoopJ: how is rpi cheap
<SnoopJ>
it isn't, now
<whitequark[cis]>
u still need the peripherals and those can run a cool dime
<whitequark[cis]>
it wasn't very cheap then either
<SnoopJ>
it was a hell of a lot cheaper than the alternatives though
<whitequark[cis]>
was it?
<whitequark[cis]>
than the alternative SBCs, at the time, sure
<SnoopJ>
unless you want to count like gumstix as an alternative, I'd say so, but maybe I'm underinformed about what was on the market
<whitequark[cis]>
than the alternatives in an educational setting? i don't see that
<whitequark[cis]>
it was so slow and shitty (plug in a mouse, as intended? half your CPU is eaten by interrupts for the USB core)
<whitequark[cis]>
that you could beat it by getting some x86 ewaste
<SnoopJ>
IIRC the goal was a computer you could literally give the student, not like "this lives in a classroom"
<SnoopJ>
but maybe I have rose-tinted glasses on here, I'm sure you know better than I do
<whitequark[cis]>
i see it as a remarkable propaganda win, but not a particularly good or cheap sbc for educational setting
<whitequark[cis]>
(rpi1)
<whitequark[cis]>
if anything i think the more recent models are better in that regard, because they're still cheap enough, very standardized, reasonably fast
<SnoopJ>
I truly do not remember there being any other SBC in that niche, closest thing I recall would be the surge of small-ish devices based on Atom
<whitequark[cis]>
why the focus on SBCs?
<whitequark[cis]>
who actually wants a bare PCB kicking around at a student's home?
<whitequark[cis]>
it's only "cheap" if you artificially limit the scope to "other SBCs" and not "give students in need computers other people do not need"
<jwise0[m]>
oh, and while I am complaining, for completeness, my political complaints about rp2040 are that: gateware source is not available (and only one thing in there is really all that innovative; if they wanted to protect PIO, they should protect it with patents); the choice of cm0 over a RISC-V serves to entrench ARM and is inherently political of a choice; and raspberry pi foundation, cops, etc
<SnoopJ>
the rhetorical construction is I think "vs. nothing kicking around at home"
<SnoopJ>
(read as: the classroom probably won't give away a tower, whether or not that's actually true to the economics of the day)
<jwise0[m]>
so RPi not as a usable computer but as a computer science education environment is a very useful distinction. sending a high school computer science student home with a board (in a 3D printed case?) that has a standardized compiler and environment is a lot easier than supporting myriad home computing environments
<SnoopJ>
but OTOH I guess it's all moot, I don't think anybody really *did* those things anyway, it rapidly turned into what it is now
<whitequark[cis]>
jwise0[m]: this is true but that was not the pitch
<whitequark[cis]>
again: great propaganda win, lackluster device for declared use
<whitequark[cis]>
it's more or less greenwashing for broadcom
<whitequark[cis]>
eduwashing?
<SnoopJ>
moral arbitrage
<whitequark[cis]>
rp2040 though is an actual product that stands on its merits and fills a useful niche etcetc, so that was what made me actually afford the foundation any respect
<jwise0[m]>
(my alma mater's CS education curriculum is about to run headlong into this, where we have a fantastic operating systems program that centers around Intel x86_32 + Simics for simulation, and the whole pitch was that x86_32 is a no-magic environment where you can test your kernel by popping it into your grub.cfg, and this is a *lot* less true now, and ... now what? RPi is an 'obvious' target with a reasonably long life, but the Simics
<jwise0[m]>
situation is astonishingly bad)
<whitequark[cis]>
shame re: cops but ah well
<SnoopJ>
yea, RP2040 is neat IMO, not that I've done anything with it, but I am not an electronics
duskwuff[m] has joined #glasgow
<duskwuff[m]>
personally my main gripe with rpi (the sbc, not rp2040) is how everyone focuses on using it for non-graphical tasks, which it is generally terrible at
<jwise0[m]>
yeah, almost every sin of RP2040's is adequately excused by '$0.70, and you can buy it'
<duskwuff[m]>
the soc was designed for use in set-top box applications; the GPU was supposed to be its major selling point
<jwise0[m]>
'you have to tie together two I/Os to work around a USB MAC issue' 'ok, but it's $0.70, and you can buy it'
<jwise0[m]>
'the programming model between the two CPUs is strangely noncoherent and requires very careful handholding to make it work' 'isn't that charming! you get to remember the good old days of tiny quirky machines! anyway, it's $0.70, and you can buy it'
<jwise0[m]>
(and I am not saying this sarcastically!)
<whitequark[cis]>
duskwuff[m]: the trash tier powervr derived gpu that doesn't have proper oss drivers?
<whitequark[cis]>
who cares?
<SnoopJ>
PicoGUS has done a lot to make me admire RP2040
<jwise0[m]>
'the reliability is a real question, and there are a lot of artifacts that the ASIC design work was "well, we'll just send it". I dunno about designing this into an industrial application' 'ok, it's $0.70, though. I guess if you care about that you could pay ST Micro $7 for the same quality engineering tho'
<whitequark[cis]>
lmfaosob
<SnoopJ>
Wondering once again if RP2040 could suffice as an MFM emulator, along the same lines as the horrifying one that uses an entire BeagleBone for this purpose, but not over-built
<whitequark[cis]>
should add that to glasgow <.<
<whitequark[cis]>
would be so easy too
<SnoopJ>
yea, especially since you've already done some related work IIRC
<SnoopJ>
(honestly the #1 temptation for me to get one, which I have not)
<whitequark[cis]>
it's like
<whitequark[cis]>
largely trivial
<whitequark[cis]>
well
<whitequark[cis]>
correction: largely trivial except for the difficult bit (i.e. where does the data go)
<duskwuff[m]>
I'm looking at this from a circa-2012 perspective, at which point OSS drivers were basically nonexistent in this space (iirc?). maybe if everyone hadn't jumped straight to using their Pis as NASes and weather stations and whatnot that might have gone differently, idk
<jwise0[m]>
that always seemed like the challenging problem of any of these bus emulators that emulate fixed access time devices, yes
<whitequark[cis]>
glasgow does not have 1.44m of anything
<whitequark[cis]>
however a floppy is not really fixed access time
<whitequark[cis]>
u can just feed the fdc noise until u load the data
<whitequark[cis]>
the roundtrip time via usb is not guaranteed but is in low ms range
<whitequark[cis]>
and then u turn usb into delay line memory
<whitequark[cis]>
(endlessly feed it the same track over and over)
<whitequark[cis]>
actually
<SnoopJ>
yea where the data goes is a bit of a trick heh. Still feels like you could do a bit better than those GoTEK MFM thingies though
<whitequark[cis]>
that just solves the problem period
<jwise0[m]>
that is not the answer I had been going towards with that.
<whitequark[cis]>
lol
<whitequark[cis]>
can someone send me anything with a floppy interface plz
<jwise0[m]>
hm, I guess it is the case that the thing with having a physical stepper between tracks is that if you step tracks, it is permissible for at least one revolution to be crap data
<whitequark[cis]>
yes
<whitequark[cis]>
and we don't need that much
<whitequark[cis]>
we need just a few milliseconds
<jwise0[m]>
I was sort of going with 'you would have tracks n and n+1 and n-1 in BRAM, and then you would ask for the track when things change', which I guess is a soft real time problem (given that at least one revolution can be garbage) rather than a hard real time problem
<whitequark[cis]>
then quite literally feed the entire track in a loop and it does not matter how long it is
<jwise0[m]>
so you can have driver software on the host that is doing something useful for you
<whitequark[cis]>
could do the MFM hard drive too
<whitequark[cis]>
how cursed is this
<whitequark[cis]>
also seek time is like 50ms even before a revolution
<jwise0[m]>
I would say 'not very'. autonomous USB delay line rather than, like, block RAM, to hold a track is fairly cursed, though interestingly, for hard drives, there is prior art on this http://tom7.org/harder/
<jwise0[m]>
50ms for a single step?? that's 20Hz. floppy drives made a much higher pitched 'broooonk' than that
<tpw_rules>
tom7 <3
<whitequark[cis]>
but there are higher frequency harmonics, no?
brolin has joined #glasgow
<jwise0[m]>
I guess the internet can trivially answer this for me.
<jwise0[m]>
apparently some older drives are as slow as 20msec steps, but many newer drives can step as frequently as 3ms. the 'head load time' is about 10ms.
<whitequark[cis]>
til
<SnoopJ>
usb delay memory 👀
<jwise0[m]>
I am not sure I understand what the 'recalibrate' command on uPD765 might do, and indeed, how a floppy head may end up centered over a track or not, though (especially given as there does not appear to be sub-track stepping?). another option for delaying output that will probably work on many controllers but could make a few of them mad, is to only emit an index hole pulse once you are ready to spit data out
redstarcomrade has joined #glasgow
<whitequark[cis]>
technically that is usb *controller* delay memory... well... it's just host memory really...
<whitequark[cis]>
oh yeah right, index hole!!!
<jwise0[m]>
rotation speed is 300rpm == 5Hz. 200ms is almost certainly enough time to go all the way back even to userspace on the host, especially if you cached adjacent steps for the best case scenarios
brolin has quit [Ping timeout: 255 seconds]
tem01[m] has quit [Quit: Idle timeout reached: 172800s]
esden[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
glasgow doesn't have enough bram to cache 3 tracks
<jwise0[m]>
I guess one will have to do
<jwise0[m]>
especially given that large seeks can take place in not much time (compared to a rotation), such that caching adjacent tracks will not save you
<whitequark[cis]>
even one!
<jwise0[m]>
well that's not great.
<whitequark[cis]>
iirc you hav 16 512-byte BRAMs
<whitequark[cis]>
and two are used by the USB interface
<whitequark[cis]>
hence, USB delay line memory
<whitequark[cis]>
there is rampak ofc
<jwise0[m]>
what is this 'SPRAM' thing? can you use it?
<whitequark[cis]>
it does not exist on revC
esden[m] has joined #glasgow
<esden[m]>
( sigh ... I need to find time to make the RAM Pak available...)
<jwise0[m]>
if you sell a thing called a RAM Pak then you have to injection mold it out of atomic purple plastic. sorry, I don't make the rules.
<esden[m]>
lol 😄
<whitequark[cis]>
we also need upstream support for rampak
<whitequark[cis]>
how do you even use that
<tpw_rules>
jwise0[m]: i concur
esden[cis] has joined #glasgow
<esden[cis]>
Yeah I don't know anything ... I don't think I even have one at the moment as I sent the one prototype I assembled to you @Catherine :D
<whitequark[cis]>
that was the ONLY ONE?
<whitequark[cis]>
... I had no idea
<esden[cis]>
the only one I have ever assembled that fits in the case
<esden[cis]>
there is one more thick prototype
<whitequark[cis]>
is there a schematic at least
<whitequark[cis]>
like I can't do anything with this thing
<esden[cis]>
yeah it should be on my github, sec
<jwise0[m]>
well, ok. what I am hearing is that I have more ammunition to tell Efinix sales man that people are struggling under the limitations of iCE40, and if only there were an open source toolchain for, say, Trion T8 ($5.48 qty1), then there is a world of people who would buy them, but can't, because Yosys is critical to the things people want to do with it.
<whitequark[cis]>
I would like to have it in the monorepo eventually
<esden[cis]>
Sure, I did that outside because it needs to get supported first and tested and yadda yadda yadda
<jwise0[m]>
(looks like you could not go as small as T4, since you lose your LVDS that way, but you get the idea)
<whitequark[cis]>
nodnodnod
<whitequark[cis]>
make sense
<tpw_rules>
ecp5+fx3 glasgow DX when
<esden[cis]>
I sent you my prototype to make sure you have one. I do have parts somewhere to build another one... but if I was sending you stuff I decided it is better to use that opportunity. :)
<whitequark[cis]>
tpw_rules: a few years?
<whitequark[cis]>
esden: yes this is a good idea I think
brolin has joined #glasgow
<esden[cis]>
Catherine: more hardware when everyone manages to dig themselves out of all the rabbit holes :P
<whitequark[cis]>
oh wow, we have 32 megabytes of data there?
<whitequark[cis]>
that's going to be pretty good for a whole host of hard realtime instruments
<esden[cis]>
Yeah it is pretty big, also I wired the chips up in parallel, to get a nice wide buss
<whitequark[cis]>
yes, 32 bits per cycle is pretty alright
<esden[cis]>
the chips are DDR too IIRC
<whitequark[cis]>
by straightforward connection to the IOs we can have the Glasgow sampling all 16 at 96 MHz
<whitequark[cis]>
this is way better than the cheap Saleae clones
<esden[cis]>
:D
<whitequark[cis]>
which pretend to do 2 at 96M but can't
brolin has quit [Ping timeout: 245 seconds]
<esden[cis]>
I did test that the hardware does work by loading a verilog test project directly into the FPGA thanks to tnt.
<esden[cis]>
So at least the hardware should be working.
<esden[cis]>
How it fits into the Glasgow framework is a very different question.
<esden[cis]>
I would think it would be some optional module one can load into an applet...?
<whitequark[cis]>
yeah, that is easy enough to organize
<whitequark[cis]>
target.get_dynamic_memory() and thats it
<whitequark[cis]>
is the clock parallel?
<esden[cis]>
I think I routed the clocks of each chip to it's own GPIO but I have to open the schematic to check
<esden[cis]>
Just in case someone wants to run them at different frequencies for god knows what reason
<esden[cis]>
let me open it up...
<esden[cis]>
I will update it to the new kicad while I am at it.
<whitequark[cis]>
that could be genuinely very useful
<whitequark[cis]>
good choice
<esden[cis]>
Ahh yes, the clocks are on separate pins and differential. IIRC you don't HAVE to run diff pair clock, it depends on the speed and config of the hyperram chips.
<whitequark[cis]>
yeah ok, this is basically perfect
<esden[cis]>
and yeah, I had just the right amount of pins so "why not" ™️
<whitequark[cis]>
means 2 applets can each use one chip
<esden[cis]>
exactly
<whitequark[cis]>
cool!!
<whitequark[cis]>
i like
<whitequark[cis]>
need to test then bless it
<esden[cis]>
😊
<whitequark[cis]>
do you know what the price would be?
<esden[cis]>
No clue at this point... I did it in the before times
<whitequark[cis]>
right!
<whitequark[cis]>
the chips seem kinda... eol
<esden[cis]>
yeah I might need to do a respin with different chips
<esden[cis]>
There are other hyperram parts that will work
<esden[cis]>
I might not even have to do all the acrobatics to run it at 1.8V
<esden[cis]>
but protocol and pinout wise it would be the same.
<duskwuff[m]>
afaik SPRAM only exists on ice40UP parts, not ice40LP/HX
brolin has joined #glasgow
<jwise0[m]>
aha
<whitequark[cis]>
we used to use UP on revab
<whitequark[cis]>
too slow
brolin has quit [Ping timeout: 240 seconds]
brolin has joined #glasgow
brolin has quit [Ping timeout: 258 seconds]
brolin has joined #glasgow
brolin has quit [Ping timeout: 240 seconds]
joerg has quit [Ping timeout: 258 seconds]
joerg has joined #glasgow
<whitequark[cis]>
I have tried actually using Docker and now I'm considering violence
<whitequark[cis]>
well, writing a Dockerfile to be more specific
<whitequark[cis]>
Docker docs: "you can use heredocs"
<whitequark[cis]>
docker: `Error response from daemon: dockerfile parse error line 8: unknown instruction: ECHO`
<whitequark[cis]>
(this happens because the buildkit docker and non-buildkit docker recognize different syntax, because this is a normal and reasonable thing to do when you're a company with essentially infinite money)
axiesmoothie[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
yeah but like, now you need all this ceremony with docker build
<whitequark[cis]>
why isn't there a single command that's like build+run anyway?
<jwise0[m]>
(the thing that you show here throws away the hermeticity of the container by apt-get installing each time you do a build -- so if you want to build an old version of Glasgow and verify that it matches, you cannot just run the script from that era, you must manually set up your Docker environment to match the old version)
<whitequark[cis]>
so it's true that apt-get install may technically decide to install a different version of sdcc
<whitequark[cis]>
however in the entire history of sdcc in Debian the patch version of sdcc has never changed within a release
smkz has joined #glasgow
<whitequark[cis]>
meaning: you can in fact run a script from that era, as long as the base image is still extant (and if not you could just install old Debian)
<jwise0[m]>
so I think the idiom for hermetic builds is:
<jwise0[m]>
* write the dockerfile; `docker build . -t whitequark/glasgow:20231024 # executes the steps in the Dockerfile, produces a hash of a version, and then tags that hash locally`, and then `docker push` that tagged build to somewhere you want people to grab it from (ha! ha! perhaps you want dockerhub? they definitely won't change the terms of use on you next week!)
<jwise0[m]>
* `docker run --rm whitequark/glasgow:20231024 -v $(pwd):/work --user $(id -u) # pulls the container image, creates a new container to operate in briefly, mounts the current directory in /work, runs the default command specified in the dockerfile, then wipes the container afterwards`
<jwise0[m]>
and the other benefit you get from this is that when you want to go do a build again, you can do so without the expense of firing up `apt` again, without even a network connection -- i.e., the `docker run` is a very quick operation (morally, 'fire up an overlayfs'), basically starting at the `make` step for free
<whitequark[cis]>
it takes 14 seconds to do the entire build
<whitequark[cis]>
right now, with apt and all
<whitequark[cis]>
I acknowledge what you said as accurate, it's just that, mm
<whitequark[cis]>
I remember once wanting a drop down menu in HTML, for a wasm port of a native app. (more accessible if not drawn with opengl). scanlime told me to use web components; I checked it out, the node_modules folder alone was like 5x the entire build tree of the native app, including the ANGLE submodule and the git repos
<whitequark[cis]>
and the component suggested didn't even do all of what I wanted
<whitequark[cis]>
so I wiped all of that stuff and wrote an implementation in bare css & js in an evening that was just fine and, imagine that, did not involve running node, babel, or ts
<jwise0[m]>
(on the other hand, it all depends on what your goals are, and I have not been following well enough to know for sure. if the goal is 'build any glasgow firmware from any point in history reproducibly at any point in the future, and develop in this context', you probably want something more bulletproof, closer to what I describe. if the goal is 'broadly, have a handful of people be able to build the current release firmware and usually
<jwise0[m]>
get a matching hex file, probably once', then what you have built will do this more than adequately)
<whitequark[cis]>
you & the nix person both propose elaborate, technically correct solutions that have one problem in common: they are a pain in the butt for no good reason
<whitequark[cis]>
the goal is the former and I posit that what I wrote achieves it
<jwise0[m]>
well, if your claim is 'this future sucks, and this kind of tooling is deeply annoying and overengineered', you will hear no argument from me
<jwise0[m]>
* no argument against that stance from me
<whitequark[cis]>
frankly, I think it achieves it *better* than uploading docker images to some third party service would
<whitequark[cis]>
because my solution has no dependency on anything but "having a debian install of a given release"
<whitequark[cis]>
(which happens to be done through docker right now, as a cheap and quick way to get that)
<jwise0[m]>
I think that you can achieve what you are trying to achieve more performantly and more reliably in, I think, fewer lines of idiomatic Docker, though, even if you never upload a docker image to a third party service
<vegard_e[m]>
sounds like a question of archival to me, i.e. whether you can trust the APT archives to always be available, or whether you should archive docker images with the relevant packages installed yourself
<whitequark[cis]>
I trust debian.org more than I trust any company or myself
<jwise0[m]>
this is not to say that you should rewrite it my way 🙂 I would be happy to demonstrate it if you like, mostly as an exercise to see if it is as easy as I think it is. but also if you think this meets your goals I would much rather you go work on other things that are more useful than appease my Docker sensibilities from an incomplete understanding of a world that Hashicorp has built, a world which is not even internally coherent in
<jwise0[m]>
its own goals
ar-jan has joined #glasgow
<whitequark[cis]>
jwise0[m]: that's vaguely interesting, but only if it is completely stateless w.r.t state managed by dockerd
<whitequark[cis]>
(that is, my requirements are: no uploads and no image management)
<whitequark[cis]>
(a single script that does the entire thing, the same every time, regardless of the environment)
<vegard_e[m]>
if you're not gonna keep the images, I don't really think it's necessary to have a dockerfile at all, you could just spin up a bare debian image, run the stuff you want in it, and throw it away after
<whitequark[cis]>
literally what i am doing, right?
<vegard_e[m]>
I admit I haven't looked too closely at what you're doing
<jwise0[m]>
in a sense, under the hood, nothing is stateless w.r.t state managed by dockerd (including the thing you have), but docker run --rm -it $(docker build -q .) would do what you want
<jwise0[m]>
well you would not want to -it but you get the idea
<whitequark[cis]>
oh, so, i started out that way
<jwise0[m]>
I should go to bed but let me mock this up. hang on.
<whitequark[cis]>
but then discovered that docker build doesn't let me use heredocs without an environment variable related to buildkit or something
<whitequark[cis]>
and that infuriated me so much I refuse to touch Dockerfiles from this point on as a matter of principle
<jwise0[m]>
yeah, broadly, if you were trying to do that specific thing, the problem is that you were trying to make a Dockerfile do your computation, rather than your setup
<whitequark[cis]>
why the fuck do you have two incompatible languages for Dockerfiles *even after the #syntax magic comment is considered*
<whitequark[cis]>
who signed off on this
<vegard_e[m]>
yeah, now I've looked; literally what you're doing
<whitequark[cis]>
jwise0[m]: I was trying to stuff the build script by COPYing it
<whitequark[cis]>
from a heredoc
<vegard_e[m]>
I think your approach is a reasonable one
<whitequark[cis]>
I would then be using ENTRYPOINT for the actual build
<jwise0[m]>
but I cannot answer this question no rdo I have any idea what the answer could be, nor even if I knew would I be willing to defend it. the only answer I have to "why does this absolutely simple functionality not work" is "because it is unidiomatic". I *think* people do not actually COPY from heredocs, and instead COPY from additional turds that they keep in their repository
<whitequark[cis]>
but if I have to set an environment var to make the docker run $(docker build) invocation work I need another script, and I'm not going to honor docker with two
<whitequark[cis]>
jwise0[m]: so it works with DOCKER_BUILDKIT=1
<whitequark[cis]>
but not without it
<whitequark[cis]>
the example with COPY from a heredoc is on the official docker blog
<jwise0[m]>
a nontraditional, but principled, stance
<jwise0[m]>
yes, I cannot defend this DOCKER_BUILDKIT=1 crapola
<whitequark[cis]>
it's not some random idea I got, it's literally from the official fucking website
<jwise0[m]>
you will not hear me defend the official fucking website either
<whitequark[cis]>
like
<jwise0[m]>
trust me, I am not defending Docker as not sucking
<whitequark[cis]>
I honestly want to grab alpine, build sdcc against musl, stuff it into jslinux and run builds using duktape
<whitequark[cis]>
but that requires setting up reproducible builds for alpine+sdcc+musl first, which is the same infuriating problem another time over
<jwise0[m]>
it is, in fact, turtles all the way down
<whitequark[cis]>
(I will never stop committing cross compilation crimes)
<whitequark[cis]>
sdcc has too much random junk in it to build it against wasm I think or I'd just do that
<whitequark[cis]>
*growls at software*
<whitequark[cis]>
jwise0: like I will freely admit you are doing it the more correct way
<whitequark[cis]>
I'm just doing what I am because I want to commit violence to Docker (the software) and this is how I do it
<jwise0[m]>
yeah I have no particular need for Glasgow to do it my way
<whitequark[cis]>
it's a question of self-expression more than anything o:3
<jwise0[m]>
I figured there was it could go either way that 1) you did not know the idiomatic way, and would prefer to do it the idiomatic way if only you were informed; or 2) you simply did not give a fuck about the idiomatic way and wanted to be done with it and merge the fucking PR and move on with your life
<whitequark[cis]>
I actually wanted to know if I'm missing something
<whitequark[cis]>
I am unhappy but content to discover the answer to be no; Docker is actually just that bad
<jwise0[m]>
agh here hang on. I will mock up the way I would do it, then I will go to bed.
<whitequark[cis]>
hehe, thanks ^^
<jwise0[m]>
god I have not done this in a long time. there is presumably a reason for that.
<whitequark[cis]>
duskwuff: oooooh, I am very interested
<whitequark[cis]>
jwise0: right, I see! one of my explicit goals was to make it all confined to a single file, easy to understand, view history of, etc
<whitequark[cis]>
if that could be a Dockerfile with some trivial invocation of it I would go with that
<whitequark[cis]>
(e.g. build script embedded as entry point)
<jwise0[m]>
(and immortalize it for all time, associated with a given github action)
<jwise0[m]>
TIL!
<whitequark[cis]>
I kinda doubt GitHub will store Docker images for all time, considering not even Docker Inc did
<whitequark[cis]>
they wipe build logs after 6mo which is actually a bigger issue
<whitequark[cis]>
and that's repetitive and extremely well compressing text
<jwise0[m]>
yeah, I think my mental model is that there are actually three components of the system anyway, and so they deserve three components which I do not want entangled in my mind anyway (morally: "the thing that drives docker"; "the thing that controls the docker container"; "the thing that runs inside the container")
<whitequark[cis]>
in my mental model Docker is an implementation detail not deserving a single top-level file dedicated to it :3
<galibert[m]>
Debian packages require a damn dedicated directory
<whitequark[cis]>
but especially not in *my* source tree
<whitequark[cis]>
galibert: and do you see a debian package here? ^_^
<galibert[m]>
Catherine: Indeed :-)
<whitequark[cis]>
this is, no joke, a part of why (not)
<whitequark[cis]>
every time I do something of public interest I try to remove myself out of the picture as much as possible
<jwise0[m]>
yes, you could heredoc into /tmp or something
<whitequark[cis]>
consider yowasp: the builds are done on GH infra and not e.g. my buildbot, and the packages are stored on PyPI and not my server, even if both would have some benefits
<galibert[m]>
sdcc is interesting. It kinda makes me want to use one of those cores for embedded control rather than some unweidly riscv
<jwise0[m]>
well, you could save the produced docker save image stored adjacent to the rest of your artifacts
<whitequark[cis]>
where?
<jwise0[m]>
in GitHub Releases or wherever else you store your artifacts?
<jwise0[m]>
or PyPI or whatever?
<whitequark[cis]>
we do not use either!
<whitequark[cis]>
it's just the repo
<jwise0[m]>
to be clear I extremely do not advocate for this
<whitequark[cis]>
I don't think I should put the docker image in the git repo.
<jwise0[m]>
yeah that seems bad.
<jwise0[m]>
in such a case, you could 'optimistically' stash images in GitHub Container Registry, I suppose.
<whitequark[cis]>
we'll maybe eventually have PyPI releases, but that is in distant future (if at all even)
<jwise0[m]>
but, to be honest, I'm sort of partial to the 'just build it with a debian snapshot sources.list' at this point.
<whitequark[cis]>
jwise0[m]: is this better than using the Debian snapshot package archive?
<whitequark[cis]>
right
<whitequark[cis]>
if I knew about snapshot.d.o I would have used that straight away; I assumed it is not something someone would maintain
<jwise0[m]>
the snapshot archive would be unidiomatic for those who speak fluent Docker.
<jwise0[m]>
but, to quote a common Mandarin phrase, 'difference not much'.
<jwise0[m]>
(a slack I am in has a :chabuduo: reactji and it is very useful.)
<whitequark[cis]>
I remember how before I started YoWASP, someone suggested I work around toolchain deployment issues by shipping glasgow itself as a docker image
<whitequark[cis]>
I think you can work out my reaction to that (it's in the IRC logs too)
<jwise0[m]>
that would neatly solve all the pick and place problems and crowdsupply problems too if it could just be shipped as a docker image
<whitequark[cis]>
lmfao
<whitequark[cis]>
just ship TSMC as a docker image
<whitequark[cis]>
no problem #VPofIdeas
<galibert[m]>
And put Esden in the DockerFile?
<whitequark[cis]>
poor esden
<jwise0[m]>
on this note, I have a halloween costume that I have not finished building, and clients who want me to do useful things for them, and I think the best solution for both of these problems is to go to sleep
<jwise0[m]>
oh I will add one more note
<jwise0[m]>
this comment is one made by someone who has not yet caused sdcc to ICE ten times in a row. save yourself the grief: slam down a VexRiscv dialed as small as it will go, and enjoy life with gcc.
<galibert[m]>
huhuhu ok :-)
<galibert[m]>
I need a better embedded libc, sigh
elena[m] has joined #glasgow
<elena[m]>
<whitequark[cis]> "just ship TSMC as a docker image" <- we have TSMC at home
<gruetzkopf>
whitequark[cis]: RE: something with floppy interface: the other glasgow on your desk? :D. i should be able to dig out some 386EX or NatSemi Geode PC104 sbc if you're interested
<whitequark[cis]>
gruetzkopf: ooooh yes please, just whichever is smallest will work
<gruetzkopf>
same size, latter platform ist just barely still supported by linux
<gruetzkopf>
also have more docs for that board
Eli2_ has joined #glasgow
Eli2 has quit [Ping timeout: 240 seconds]
icb[m] has joined #glasgow
<icb[m]>
Re: RAM-Pak, I wonder if trying one of the HyperFlash chips would be useful (or one of the hybrid HyperRAM/HyperFlash chips, but IIRC those have a second chip select). I'm thinking like for that MFM drive emulator idea, having non-volatile storage would be useful
brolin has joined #glasgow
brolin has quit [Ping timeout: 240 seconds]
<galibert[m]>
Do we really need another gotek?
<gruetzkopf>
no ToCToU attacks on weird machines with gotek
<gruetzkopf>
"generic pc-compatible-disk mass storage emulator" is really the least interesting thing i can imagine here
<galibert[m]>
not sure of the level of capability of flashfloppy, but I don't think it's that bad
<galibert[m]>
the #1 problem with floppy emulators is having enough ram to store a whole track
<galibert[m]>
especially if you want to be able to go flux level
brolin has joined #glasgow
brolin has quit [Ping timeout: 258 seconds]
brolin has joined #glasgow
brolin has quit [Ping timeout: 255 seconds]
brolin has joined #glasgow
brolin has quit [Ping timeout: 240 seconds]
<icb[m]>
If we could only have one solution in for each problem, the world would be a boring place. Plus, are Gotek devices OSHW?
<icb[m]>
s/in//
<tpw_rules>
i tested and the firmware does reproduce
nkt_disc0rd[m] has quit [Quit: Idle timeout reached: 172800s]
<tpw_rules>
(curious how you describe involving nix as a pain in the butt)
joerg has quit [Ping timeout: 258 seconds]
<galibert[m]>
icb: so many things to do, so little time
<whitequark[cis]>
<tpw_rules> "(curious how you describe..." <- installation of the nix tools on e.g. debian
brolin has joined #glasgow
<ar>
installing nix on non-nixos isn't terribad. the problem is that some distros provide a package that's usually outdated or broken in some subtle way, and users end up using that because "it's already in the repo", instead of using the official installer ;/
<whitequark[cis]>
yes, that's exactly the part that is a pain
<whitequark[cis]>
also i just don't really want to be using the official installer
<whitequark[cis]>
like, glasgow does not have an "official installer"
<whitequark[cis]>
it could. it doesn't because i dislike the idea and because i would rather bite the bullet and take the pain of interoperating with several other tools
<whitequark[cis]>
meanwhile you can use Docker that is in the repo of some ??? ancient version or whatever and it works Fine
<whitequark[cis]>
(arguably the reason it works Fine in this case is because Docker is a deeply unambitious application of which I am using very little, but like that's intentional, right)
<ar>
uh. i've been burned by using (ancient) distro-provided docker a few times
<whitequark[cis]>
i like nix and i use nix specifically to achieve things i would otherwise be too disabled to sustain
<whitequark[cis]>
but i don't think i want to use it here
<ar>
(and the tools surrounding docker, like compose)
<elena[m]>
whitequark[cis]: what, don't you like the farm fresh curl to bash pipeline.
<whitequark[cis]>
oh, i have absolutely no tolerance for docker-compose
<SnoopJ>
signed
<whitequark[cis]>
elena[m]: hey i would probably embed the sha1 of the script in the pipeline you copy&paste somehow
<whitequark[cis]>
we should make an application called curlbash that has a --sha1 option
<whitequark[cis]>
then everyone can use that
<elena[m]>
curlybash, bash with a curly wig
<whitequark[cis]>
actually i'm curious whether curl already has the option
<ar>
elena[m]: given the (virtually nonexistent) security model of just about every linux distro other than qubes, the way you install something is IMHO least of your concernes
<whitequark[cis]>
ar: i disagree
<whitequark[cis]>
if you install the same thing everyone else does, then what hits you will be the same as what hits the others
<whitequark[cis]>
there is some measure of transparency, especially considering that the script typically downloads a well known public artifact like a binary release
<whitequark[cis]>
if you install just Whatever this automatically becomes the juicest possible vector for TLS interception, replacement at the edge, <anything anyone can do to it>
<whitequark[cis]>
like there was a recent case where someone issued fake acme certificates for jabber.ru (a russian xmpp server) by having their hosting provider cooperate with, probably, cops, and then redirected TLS connections to jabber.ru to some other server transparently
<whitequark[cis]>
this isn't some nation state level attack, this is just "I have an insider at their hosting provider or otherwise have them cooperate" level attack, which is like really easy to pull off
<whitequark[cis]>
could do via BGP too
<elena[m]>
i just want things to be awful in a broadly consistent way rather than awful in an exciting and unique way according to the capricious whims of the script writer
<whitequark[cis]>
>_>
<whitequark[cis]>
* \>\_>
<ar>
(given my own experience with hetzner, they'd let anyone holding something smelling vaguely similar to a warrant do something like that)
<whitequark[cis]>
yep!
<whitequark[cis]>
you should probably still not host the webpage with the sha1 on the same host that would be subject to interception by cops with the same TLS cert, probably
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
brolin has quit [Ping timeout: 255 seconds]
<whitequark[cis]>
oh that's interesting
<whitequark[cis]>
a new commit to Amaranth caused the Glasgow tests to start failing, because we do not specify an exact git revision in the dependencies
<whitequark[cis]>
i, hm. so i was clearly a lot more inexperienced with nix rather than docker, and nix is a lot less painful than i thought it would be
<whitequark[cis]>
also it built with nix from debian
<whitequark[cis]>
tpw_rules: what is your github username?