ChanServ 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, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<whitequark>
cr1901_modern: have you tried like a sex dungeon instead or something
<whitequark>
it's less expensive
<Foone>
I've joked about making a modern game but having it dump you in a text-only SETUP program before you can run it, and making you select your sound card out of a list
<cr1901_modern>
Suggestion noted :3
<whitequark>
lol
<Foone>
and populate it by spelunking the windows device manager to get the actual name of your audio device
<Foone>
so it'd be like ADLIB, SOUNDBLASTER, INTEL HD AUDIO, GRAVIS ULTRASOUND
<whitequark>
GRAVIS LIZARD
<Foone>
and if you're playing on hard mode, make you select the correct memory range, too
<cr1901_modern>
ASMR whispering/Humiliation while I help you install Elder Scrolls Arena from floppy disk
<Foone>
no one is doing intel HD audio (azalia) from DOS yet but once you get past the PCI/PCIE enumeration step it's just a memory offset with a bunch of memory mapped registers so you could just program it directly
<whitequark>
pcie requires no additional enumeration steps
<cr1901_modern>
What is azalia?
<whitequark>
codename for intel hda
<cr1901_modern>
Ahhh
<whitequark>
also, does dos actually do pci enumeration, i forget
<whitequark>
it predates pci right
<Foone>
very much predates it
<whitequark>
or... does it?
<whitequark>
right so you can just do it yourself and hog the entire bus
<Foone>
some drivers do their own independent PCI enumeration but they're rare
<whitequark>
i'd consider writing azalia driver for dos but:
<cr1901_modern>
The Lava serial port cards have their own drivers
<cr1901_modern>
that work from DOS
<whitequark>
a) i hate openwatcom. i've never used it i hate even the idea
<whitequark>
b) azalia is horrifying
<Foone>
these are all good reasons not to do it, yes
<whitequark>
like... can i . uh .
<whitequark>
can i
<whitequark>
oh i have an idea
<whitequark>
like. a com file that sets up basic protected mode and loads an ELF file of your choice
<whitequark>
wait
<whitequark>
you have to return from that to call dos right
<cr1901_modern>
yes, that's the gist of DPMI
<whitequark>
... set up v86... oh
<whitequark>
dpmi
<whitequark>
yeah. is there a way to dpmi load an elf file
<whitequark>
so i can just like. use rust
<cr1901_modern>
The person who got COM files to work in Rust was working on that
<cr1901_modern>
last I talked to him
<whitequark>
maybe just set me up with an openwatcom scaffold that enables (?) dpmi and i'll do the elf loading step. or do it yourself
<Foone>
good question. probably not? there's a linux loader thing that is designed to boot linux over DOS, and there's that weird HX extender that supports win32 programs
<whitequark>
i wrote so many elf loaders
<whitequark>
yeah see above i can just write Yet Another ELF Loader
<cr1901_modern>
An ELF loader (AFAIK) is not hard to do
<whitequark>
it's like 200 lines
* cr1901_modern
has never done it
<whitequark>
with error handling
<whitequark>
i even have c code you can use right away
<Foone>
you could always write a loader in djgpp, so it'll set up 32bit mode for you with C/C++ and you just load the ELF from there and call into rust
<cr1901_modern>
I would be concerned about how to crashland back to DOS without destroying the first 1MB of RAM (incl the 384kB hole at the top). What does Linux do when switching to pmode?
<cr1901_modern>
Actually that's not a good question
<whitequark>
nonononono dont touch linux
<cr1901_modern>
b/c Linux doesn't need to preserve anything under 1MB
<Foone>
yeah, that's basically how the linux-from-DOS loader worked
<Foone>
used enough DOS code to load the bootloader from a DOS file, set up 32bit mode, then jumped into linux without looking back
<Foone>
no return to DOS
<Foone>
in any case, if I actually wanted to do anything with azalia I'd have to do it as a pseudo-VM like emm386 so I could capture port-writes so it'd probably have to all be 16bit assembly anyway
<Foone>
so there are many good reasons not to do it, then
<Foone>
I knew a guy with almost exactly that name in college! Good ol' Dusty Ross.
<cr1901_modern>
dunno if it works right now- it'll generate a bare COM. Next step would be to get it to generate "bare metal" elf
<cr1901_modern>
(if that's not a thing, I'm sorry)
<TD-Linux>
oh that's llvm's code16 target
<cr1901_modern>
it'll target 386 and above AIUI
<whitequark>
bare metal elf is a thing
<whitequark>
i mean
<whitequark>
there's no real requirement for an OS inherent in ELF
<whitequark>
it's very easy to support executables and even shared libraries on bare metal
<TD-Linux>
I mean, most microcontroller toolchains use elf
<cr1901_modern>
True
<whitequark>
they objcopy it to binary first
<whitequark>
but i mean you could load elf on bare metal directly
<whitequark>
as long as your bootloader can do it
<cr1901_modern>
For STM32 work, I use the elf image and openocd
<cr1901_modern>
http://lkml.iu.edu/hypermail/linux/kernel/9604/1733.html Also, TIL... "If you say mem=32m to linux, it will use all memory from 4K to 768K, then from 1024K to 32MB, omitting the 384K hole at <1024K automatically."
<whitequark>
you kinda have to do it
<cr1901_modern>
wonder what's special about 4kB
<whitequark>
oh
<whitequark>
kernel null pointer deref protection, i assume
<cr1901_modern>
oh right
<TD-Linux>
I wonder how good the llvm code16 backend is
<cr1901_modern>
also I think that's a typo (should be 640kB)
<whitequark>
it's not good afaik
<TD-Linux>
that's actually generating real mode code. not like djgpp at all
<whitequark>
code16 is basically "the minimum amount we can get away to compile linux"
<cr1901_modern>
gcc's code16 will not give you 8088 compat code
<cr1901_modern>
so I assume llvm won't either
<whitequark>
it'd be easy to adjust llvm's isel to fix that?
<whitequark>
if you tell me what needs change i could try
<cr1901_modern>
I wouldn't know I'm afraid
<cr1901_modern>
There _is_ an 8088/6 gcc port.
<TD-Linux>
rust on wonderswan development, finally
<cr1901_modern>
It was made by someone at Mentor as an April's Fools Joke a few years ago
<cr1901_modern>
and it worked!
<whitequark>
lol
<cr1901_modern>
TD-Linux: I think the segment crap would make Rust dev difficult for WonderSwan. The "easiest" solution I can think of is use huge pointers for everything and "pray they are normalized"
<cr1901_modern>
>(10:18:39 PM) cr1901_modern: I wouldn't know I'm afraid
<cr1901_modern>
Oh actually I do know one thing that code16 does that 8088 code doesn't like
<cr1901_modern>
on 8088 only bx can be used for indirect
<cr1901_modern>
on 386 eax, ecx, ebx, and edx can, and code16 happily does so
<whitequark>
that's trivial to fix i think
<TD-Linux>
wonderswan only has 64KB of RAM which "helps"
<whitequark>
i'd need some LLVM IR that produces incorrect output though
<cr1901_modern>
I'm sure I can find plenty of those that crash the 286 lmao
<cr1901_modern>
TD-Linux: What are ROM sizes on Wonderswan like? Is it bank switched or relies on far jumps to get more than 64kB of code?
<cr1901_modern>
the 64kB of RAM is _really_ good.
<cr1901_modern>
It means that SP and DS can point to the same place and the compiler need not give a crap about the gory details
<cr1901_modern>
Well, it looks like you have to do far jumps to access code beyond 64kB away from your current destination (and near/far is why, well, 8088 kinda blows for anything except assem- oh who am I kidding, it always sucked)
<cr1901_modern>
whitequark: Apropos of nothing: Is your PCMCIA laptop still alive somewhere in the depths of your workbench?
<whitequark>
yes
<whitequark>
but i'm in hong kong
<whitequark>
i can yell at my roommate to turn it on i think
<whitequark>
it'd be... difficult
<cr1901_modern>
No need to right now. I was just wondering.
<cr1901_modern>
I got really far in the PCMCIA DUMPCIS program. I just needed a break from writing out all the data structure boilerplate lmao.
<whitequark>
ahh nice
<cr1901_modern>
I think the current status is to "just" iterate over all tuple types supported as they're seen, and then memcpy them into the various tagged unions I created for each tuple type
<cr1901_modern>
And then you have your shiny new, 20 years out of date PCMCIA query program
<whitequark>
yep
ej5 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 264 seconds]
natarii has quit [Ping timeout: 264 seconds]
natarii has joined ##yamahasynths
Xyz39808 has quit [Ping timeout: 250 seconds]
Xyz_39808 has joined ##yamahasynths
Sarayan has joined ##yamahasynths
* Sarayan
waves
* ZirconiumX
waves back
<Sarayan>
I'm having fun in quartus' files :-)
<ZirconiumX>
How do you mean?
<ZirconiumX>
.qpf and .qsf files are just TCL :P
<Sarayan>
I mean ddb, hdb, hdbx, etc
<ZirconiumX>
I don't find the databases all that useful, but help is always welcome
<Sarayan>
Oh, you decompress/interpret them already?
<Sarayan>
I mean, the floorplan of the fpgas seem to be in there, so that can be useful
<ZirconiumX>
I haven't touched them; the metadata is nice but I can copy it manually from the chip planner :P
<ZirconiumX>
Though the data would be nice all the same
<Sarayan>
:-)
<Sarayan>
well, working on it
<ZirconiumX>
The SoCs are going to be painful without them
<Sarayan>
roughly, I aim at reimplementing quartus_arm, roughly
<Sarayan>
like, roughly, right
<Sarayan>
quartus_asm
* Sarayan
tickles whitequark
<ZirconiumX>
Well, asm is a *little* problematic
<ZirconiumX>
"asm" meaning "quartus_asm"
<ZirconiumX>
Which outputs .sof files, not .rbf file
<ZirconiumX>
s
<Sarayan>
asm outputs rbf here
<Sarayan>
tried with NES mister stuff
<ZirconiumX>
What are you targeting?
<Sarayan>
the DE10 one
* ZirconiumX
wonders if they missed a command line arg
<ZirconiumX>
Yeah, I have a MiSTer too :P
<Sarayan>
I don't have one (yet ;-)
* ZirconiumX
hopes it keeps its magic smoke firmly contained inside
<Sarayan>
but it's a good target
<ZirconiumX>
Have you seen the chip planner?
<Sarayan>
set_global_assignment -name GENERATE_RBF_FILE ON
<Sarayan>
I think so
* ZirconiumX
facepalms
<Sarayan>
in NES.qsf
<ZirconiumX>
Now I don't need to call quartus_cpf anymore :P
<Sarayan>
cpf generates the rbf from the sof?
<ZirconiumX>
Yep
<ZirconiumX>
Convert programming files
<Sarayan>
heh
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 250 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
Ultrasauce has quit [Ping timeout: 250 seconds]
Ultrasauce has joined ##yamahasynths
Xyz39808 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
andlabs has quit [Ping timeout: 258 seconds]
<cr1901_modern>
Sarayan: Are you still using nmigen?
<Sarayan>
cr1901: yes, slowly
<cr1901_modern>
Sarayan: Is there _any_ possibility you'd be willing to add a quartus backend to nmigen for building?
<Sarayan>
I'm hitting some conceptual issues I'll have to bug whitequark about
<whitequark>
yeah, which?
<whitequark>
cr1901_modern: i might be able to
<Sarayan>
Oh, you're here, hi you
<whitequark>
Sarayan: yeah i haven't realized tickle means ping
<cr1901_modern>
whitequark: If you're able to, that's fine too. I just can't do it/test myself.
<Sarayan>
wq: soft ping :-)
<whitequark>
cr1901_modern: why not
<whitequark>
just curious
<whitequark>
cr1901_modern: also. it's not quartus
<cr1901_modern>
My only Altera board is 10 years old, and Quartus' back compay sucks
<whitequark>
it's some specific altera family
<cr1901_modern>
oh it's not?
<whitequark>
like we have ice40 and ecp5 backends
<cr1901_modern>
oh right right
<whitequark>
but not diamond and icecube backends
<whitequark>
so which family
<cr1901_modern>
I only have Cyclone II board right now
<whitequark>
i bought this 2 TB SSD so now i can install ALL of the shitty vendor toolchains
<whitequark>
thing was fucking expensive but worth it
<cr1901_modern>
Ahhh I se- WHAT?!
<whitequark>
oh i already filled a quarter of it, shit
<cr1901_modern>
50 copies of llvm
<whitequark>
"WHAT" re: what
<cr1901_modern>
"WHAT" == 2TB SSD is huge :P
<Sarayan>
How do I handle busses is the general question. It can be at the chip borders (but I want to be able to combine chips in the same fpga to build a system) like a data bus that's 0/1/Z or more amusing the 6522 ports that are open collector (weak pull/0) or even 0/1/weak pull (yes, it drives the 1). But it's alst internal, like in the 68000
<whitequark>
cr1901_modern: well it's the largest i could find on the local market.
<whitequark>
they literally don't get huge-r
* cr1901_modern
nods
<whitequark>
well
<whitequark>
in m'2 form factor
<cr1901_modern>
whitequark: Anyways, I could purchase a Cyclone IV board in the near future, but Idk if I would make the 0.1 cutoff. So I figured asking someone else to do it would be okay :P
<Sarayan>
the 68000 has 3 optionally connected 16-bits busses, where you have one read and 2 write ports acive on a given branch, possibly through the connections
<whitequark>
cr1901_modern: even cyclone iv is EOL
<Sarayan>
cr1901: why not a V?
<whitequark>
actually
<Sarayan>
e.g. the de10 of mister
<cr1901_modern>
b/c I thought de10 was a IV
<whitequark>
quartus 19 only supports stratix/arria/cyclone 10.
<cr1901_modern>
that's it
<cr1901_modern>
If de10 is a V, no problem
<cr1901_modern>
or de0 nano*
<Sarayan>
yeah, de10 is a V, the biggest variant with dual-arm in it
<whitequark>
Sarayan: regarding buses.
<whitequark>
modern FPGAs no longer have inner tristate buffers
<whitequark>
(because they grew in size, and so did capacitive loading, and so timing hit the bottom)
<Sarayan>
makes sense
<whitequark>
that means you have to have one bus in each direction, some OE signals, and some mux logic
<whitequark>
bonus points for making a formal assertion for oe1&&oe2 and finding a bug in their design :p
<Sarayan>
A system bus usually has more than two attachment points
<whitequark>
sure, however many.
<whitequark>
note.
<whitequark>
you can use nmigen's Record to connect buses together
<Sarayan>
even something as small as the oric 1 has 5 on the main data bus (cpu, ula, via6522, ram, rom)
<whitequark>
you generally do not want to use multiplexers for more than 2 points
<Sarayan>
how do you handle it then?
<whitequark>
what you want is you want to logic-OR all the output signals
<whitequark>
but before the OR, you should look at OE and if it's low, force all the output signals to 0
<whitequark>
this is significantly cheaper than multiplexer trees
<Sarayan>
so two busses is at the chip border, not between the chips
<whitequark>
sure. I don't understand the significance
<whitequark>
this is a general transformation of tristate buses to non-tristate
<Sarayan>
"that means you have to have one bus in each direction"
<whitequark>
it's basically having an open-collector bus simulated in software
<Sarayan>
just making sure what it means
<whitequark>
in gateware*
<whitequark>
hm
<whitequark>
ah sorry
<whitequark>
ignore that remark
<Sarayan>
works
<whitequark>
so if you have e.g.
<Sarayan>
yet, well, you need the output that goes before the or and the input that comes after
<whitequark>
wire [15:0] bus;
<whitequark>
assign bus = oe1 ? o1 : 'z;
<whitequark>
assign bus = oe2 ? o2 : 'z;
<whitequark>
assign i1 = bus; assign i2 = bus;
<whitequark>
you transform this mechanically to:
<Sarayan>
you're talking verilog there, right?
<whitequark>
yes. wait. do you know verilog
<whitequark>
i forget
<Sarayan>
not really. I can gues
<whitequark>
oh
<Sarayan>
guess though
<whitequark>
ok scratch that then
<Sarayan>
I've learned vhdl two lives ago
<whitequark>
so let's say you have a pad structure
<Sarayan>
I'm getting what it means though
<whitequark>
it has i, which is the input signal, o, which is the dirving signal, and oe, which enables drivers.
<whitequark>
if you have the set of {i1,o1,oe1} {i2,o2,oe2} and so on
<whitequark>
(but for stupid reasons yosys currently infers worse netlist for it)
<Sarayan>
heh
<Sarayan>
side project #365254 is making yosis/nextpnr talk cyclone V
<Sarayan>
shopping, later
<whitequark>
isn't that what ZirconiumX is doing?
<cr1901_modern>
Quartus 19 only supports cyclone 10, huh? Interesting. "10" is a "V" variant, AIUI. But both Arria/Stratix are not hobbyist FPGAs. Wonder if Intel is trying to leave low end market.
<whitequark>
19 only has the "Pro" version yeah
<whitequark>
>Note: The Quartus Prime software is a full-featured EDA product. Depending on your download speed, download times may be lengthy.
<whitequark>
incredible
<whitequark>
oh what the fuck
<whitequark>
i need to register on intel.com??
<ZirconiumX>
cr1901_modern: that's not quite true
<ZirconiumX>
The 10GX is a V derivative
<ZirconiumX>
But the 10LP is a IV derivative
<cr1901_modern>
Ahhh, well. I'm still very curious if Intel is phasing out the consumer/hobbyist line
<cr1901_modern>
even a low-end Arria is expensive
<ZirconiumX>
whitequark: sadly, yes
<ZirconiumX>
Even though it literally just hands you a download.altera.com link
<whitequark>
if you want me to add it to nmigen give me the device support package link.
<whitequark>
it's completely unusable
<whitequark>
ah, i guess the "lite" version has the device support
<whitequark>
"44 minutes left" ugh
<whitequark>
i hate this
<cr1901_modern>
Is it 50GB like Vivado?
<whitequark>
no it's 6 GB
<whitequark>
it's just hosted on the north pole over ADSL
<Sarayan>
re
<Sarayan>
cr1901: yes, it does
<Sarayan>
wq: yeah, I plan to help ZX in fact
* ZirconiumX
reminds everybody that #prjmistral exists
<ZirconiumX>
whitequark: unrelated, but on the scale of cursed instruction sets, where does Itanium lie?
<Sarayan>
ZX: unstable power at home, which is why I don't hang on irc lately
<ZirconiumX>
Failing that I do have an email address
<Sarayan>
ZX: Yeah, I'll send you a pile of stuff once I've finished decoding them. Right now the one file I broke is not really interesting
<Sarayan>
(ddb_cumulative_family.ddb)
<whitequark>
altera qsf files are kind of weird
<whitequark>
what are sof and rbf?
<whitequark>
ZirconiumX: hey question
<ZirconiumX>
whitequark: qsf and qpf are just TCL commands
<whitequark>
does altera have different families that are like
<whitequark>
that differ in primitives
<ZirconiumX>
Yes
<whitequark>
what are they
<ZirconiumX>
I don't have any official names for them as of yet
<whitequark>
let me rephrase
<whitequark>
i'm interested specifically in IO buffer primitives
<ZirconiumX>
I haven't investigated those as of yet
<whitequark>
and also qsf file format but I assume that's identical across the board
<ZirconiumX>
So, qsf I can help with
<whitequark>
are you familiar with nmigen at all?
<Sarayan>
wq: rbf is the bitstream
<ZirconiumX>
Vaguely? I tried to write some stuff in it but got a bit frustrated and went off to learn Verilog instead
<whitequark>
huh, i'd be interested in feedback re frustrations
<whitequark>
it's supposed to be well, significantly less frustrating than verilog :p
<whitequark>
kind of the whole point
<ZirconiumX>
I think I'd prefer variable shadowing for it, but that's just me
<ZirconiumX>
We talked a bunch about it in #m-labs so I just dropped it
<whitequark>
oh I see, you wanted impossible semantics
<whitequark>
ok
<ZirconiumX>
thanks /s
<whitequark>
no, i mean, it's impossible to do that as a python dsl
<ZirconiumX>
I realise this
<ZirconiumX>
Regardless: Quartus stuff
linkmauve has quit [Ping timeout: 245 seconds]
<ZirconiumX>
whitequark: Inspecting the altera primitive simulation cells shows things which look like IO buffer primitives
<whitequark>
sure. the reason i asked about nmigen is because, if nmigen is to gain quartus support
<whitequark>
it's necessary to implement SDR and DDR IO buffers and differential buffers as well
<whitequark>
and i can't test it.
<ZirconiumX>
Just to check: are you asking about IO buffers to learn how to do this for SDR or DDR, or are you asking for primitives for specifically SDR/DDR?
<whitequark>
nmigen has a feature where you can ask "give me SDR/DDR buffer for this pin" and it instantiates the correct platform primitive.
<whitequark>
so I would need to implement it for quartus
<whitequark>
since DDR buffers can't be described behaviorally.
<ZirconiumX>
Are you okay with me linking copyrighted sim cells so you can view them, or do you want me to describe them?
<whitequark>
I don't care a single bit about copyright
<cr1901_modern>
Does Terasic have like an exclusivity agreement w/ Altera/Intel to create dev boards? I find a notable lack of Altera dev boards for hobbyists, and only by Terasic
<cr1901_modern>
even before icestorm was ready, I saw _plenty_ of Xilinx dev kits
<cr1901_modern>
from multiple manufacturers
<whitequark>
anyone can get Xilinx deices
<whitequark>
especially the lower end ones
<ZirconiumX>
I think they do: Terasic boards are used in the University program
<ZirconiumX>
Which I doubt is an accident
<whitequark>
huh, why does de10nano use two clocks for the FPGA
<whitequark>
at the same frequency
<ZirconiumX>
...Maybe one for ARM and one for the FPGA itself?
<whitequark>
bank 3b and bank 4a...
<whitequark>
oh i see
<whitequark>
it's cuz you can configure the clock chip
<cr1901_modern>
is the ARM _on_ the cyclone or a separate chip?
<Sarayan>
on
<Sarayan>
in, even
<whitequark>
is it the "HPS" thing?
<ZirconiumX>
Yeah
<ZirconiumX>
It's on-chip
<ZirconiumX>
A SoC
<whitequark>
"AF26" how large is that chip exactly
<ZirconiumX>
The one on the DE-10?
<whitequark>
yes
<whitequark>
does quartus not distinguish between "device" and "package"?
<whitequark>
5CSEBA6U23I7
<ZirconiumX>
In ALMs, or?
<whitequark>
5C is Cyclone-V
<whitequark>
what's the rest of this salad
<ZirconiumX>
5CSEBA
<ZirconiumX>
Cyclone V SE Base
<whitequark>
aha
<ZirconiumX>
The actual device name here is a 5CSEBA6U23I7NDK
<ZirconiumX>
The N is irrelevant (RoHS compliance)
<ZirconiumX>
A6 = 110K LEs (40K ALMs)
<ZirconiumX>
U = UBGA
<ZirconiumX>
23 = 672 pins
<whitequark>
what.
<whitequark>
none of these numbers match each other. why
<ZirconiumX>
The tools can optionally update the .qsf file; those options disable it
<whitequark>
aha
<whitequark>
thanks
<ZirconiumX>
Also
<ZirconiumX>
You'll find quartus_cdb to be of use
<ZirconiumX>
(compiler database)
<whitequark>
cdb?
<ZirconiumX>
cdb can dump a netlist to Verilog (--vqm), and also back-annotate routing information to both your .qsf and a routing constraints file (.rcf)
<ZirconiumX>
If you want to invoke tools manually, I have a rough script for it
<ZirconiumX>
And --rev (revision) is Quartusese for "project name"
<ZirconiumX>
quartus_map will create a project if it doesn't exist, providing you specify a name and a revision
<ZirconiumX>
I am well aware of the tautology of that
<whitequark>
um
<whitequark>
i... ok
<whitequark>
sure
<whitequark>
whatever flows intel's boat
<whitequark>
did they try buying a less cursed vendor.
<whitequark>
how do i constrain a clock
<ZirconiumX>
Uh, hang on
<ZirconiumX>
It's a Synopsys file thing
<ZirconiumX>
Critical Warning (332012): Synopsys Design Constraints File file not found: 'LABCELL_X1_Y1_N0.sdc'. A Synopsys Design Constraints File is required by the Timing Analyzer to get proper timing constraints. Without it, the Compiler will not properly optimize the design
<whitequark>
hm
<ZirconiumX>
I'm guessing that's what you're looking for?
<whitequark>
I think I had code for .sdc somewhere
<whitequark>
aaaaa the quartus download is a tarbomb
<whitequark>
why
<ZirconiumX>
Oh, and you have to spam the EULA
<whitequark>
i have to what
<ZirconiumX>
It prints the entire thing to stdout
<ZirconiumX>
Page at a time
<ZirconiumX>
There are like 25 of them
<ZirconiumX>
Unskippable
<whitequark>
incredible
<ZirconiumX>
So you have to mash the enter key to get through it
<ZirconiumX>
Have fun with that
<whitequark>
"the #1 in performance and productivity" YEAH NOPE
<ZirconiumX>
I think if you go too far though the "do you agree to the EULA" defaults to "no", so if you hit enter it exits and you have to go through it again
<whitequark>
thanks i hate it
<whitequark>
ok does it have like a bash file with the build environment
<whitequark>
/opt/quartus/18.1/home/whitequark/intelFPGA_lite/18.1 i'm sorru what the fuck did it just install to
<Sarayan>
18.1?
<whitequark>
yes.
<Sarayan>
yep, that's the version I have too
<Sarayan>
good
<TD-Linux>
that's my favorite home directory too
<TD-Linux>
10/10 rebranding effort
<whitequark>
lol
<whitequark>
AAAAAA
<whitequark>
the quartus qenv script does not work with `set -e`
emily has joined ##yamahasynths
<ZirconiumX>
Welcome to the unlikeliest place for FPGA talk
<cr1901_modern>
Sarayan: How do you plan on handling latched logic in your 68k impl?
<Sarayan>
cr1901: Right now I don't plan to do the 68000, it's a *little* too complex
<cr1901_modern>
ahhh
<ZirconiumX>
I mean, there's TG68/FX68k
<ZirconiumX>
In a pinch
<whitequark>
is it really async?
<whitequark>
i don't think it is
<whitequark>
i tried pausing the clock for like a minute with no effect
<whitequark>
well, specifically OPL2 iirc
<cr1901_modern>
I was thinking OPM. Idk about OPL2. But maybe there's no problem in that case :)
<cr1901_modern>
I'm going by timing diagrams for reg wr/rds for OPM/YM2151; there's no clock signal.
<whitequark>
it's clocked by the master clock no?
<whitequark>
it's a ring shift register thing
<whitequark>
on opl2/opl3 this is definitely true
<whitequark>
it's read/written when the right register travels across the port
<cr1901_modern>
oh I'm explaining badly
<cr1901_modern>
I think the actual reg file implementation is async latches; the rest of the chip is indeed sync
<whitequark>
oh, i see
<whitequark>
that might be
<cr1901_modern>
So I'm guessing the async parts for an FPGA implementation of a Yamaha chip won't matter because the rest of the chip can't tell the difference between an async or sync reg file
<cr1901_modern>
(if you implement it properly)
<whitequark>
yeah
<whitequark>
the timings on that port aren't even important
<whitequark>
all the vgm files are like plus minus a hundred cycles
<cr1901_modern>
Right. And even on contemporary hardware, I highly doubt two playthroughs of the same song at different points have the same _exact_ output from the chip.
<whitequark>
especially on the ones with iDAC
<whitequark>
speaking of which
<whitequark>
who wants to handhold me through measuring the response of the DAC?
<whitequark>
how do i even do that
<cr1901_modern>
freq response?
<whitequark>
whatever nonlinearity it introduces
<whitequark>
i don't even know where to start
<whitequark>
but like
<whitequark>
i want the glasgow applet to simulate the shittiness of the DAC with some DSP
<whitequark>
cuz it makes the sound richer. supposedly. i wouldn't remember
<Sarayan>
ym is very very very sync
<whitequark>
yeah it wouldn't make sense for it to not be sync
<whitequark>
it's so digital anyway
<Sarayan>
everything is done on clk or /clk, there are a billion capacitors but it's just to keep the state because it's also very very very dynamic
<whitequark>
wait, what
<whitequark>
opl2 doesn't seem to suffer from stopped clock one bit
<Sarayan>
well, 2203 would surely suffer
<cr1901_modern>
Guessing OPL2 is CMOS
<whitequark>
oh wait i have the cmos versions of every chip
<cr1901_modern>
some of them are NMOS
<Sarayan>
very possible they went pure static when switching to cmos
<cr1901_modern>
whitequark: Re: DAC, start with integral/differential nonlinearity. Those are the classic metrics, and I'm handwaving b/c I don't remember how they work :P.
<TD-Linux>
neither tg68k nor fx68k work on open source toolchains yet
<cr1901_modern>
Are they VHDL?
<TD-Linux>
tg68k is vhdl and fx68k is systemverilog
<cr1901_modern>
well, they will probably never work on FOSS toolchains then :)
<whitequark>
never is a strong word
<TD-Linux>
I've started translating tg68k to verilog but it's a bit of a struggle as tg68k is not "good" vhdl
<whitequark>
i'm sure yosys can be extended with some sv support
<whitequark>
"good" vhdl?
<TD-Linux>
fx68k is close to working on verilator at least
<cr1901_modern>
that's good
<TD-Linux>
main issue is that it uses interfaces that combine sync and async signals which verilator hates
<emily>
i like how it decided to stop highlighting set_global_assignment after the first line?
<emily>
oh, because nginx uses ;-termination
<ZirconiumX>
Wait, whitequark
<ZirconiumX>
Try running a `quartus_cdb --vqm=foo.vqm` and inspecting the Verilog output in foo.vqm
<ZirconiumX>
It's possible Quartus has helpfully decided to rename your cell for you
<emily>
out of curiosity, why reverse-engineer the intel/altera fpgas, if they're like xilinx but even more cursed? do they have some interesting property xilinx fpgas don't, or is it just for the fun/intellectual interest/~greater FOSS good~ of it?
<ZirconiumX>
...If only it were so noble
<ZirconiumX>
They seem to be only superficially like Xilinx
<whitequark>
yeah they're not like xilinx at all
<whitequark>
they're just "more cursed than xilinx"
<whitequark>
and extraordinarily badly documented
<ZirconiumX>
Xilinx's bitstream seems to be a lot more structured than Altera's
<ZirconiumX>
But who couldn't love an FPGA company with a primitive name like HPSINTERFACEPERIPHERALSPIMASTER_X52_Y72_N111, eh?
<whitequark>
i'm going to go get drunk
<emily>
ah, well, to rephrase "like xilinx" - I meant more like "big beefy expensive parts with cursed proprietary toolchains", I guess
<ZirconiumX>
:q
<ZirconiumX>
...
<ZirconiumX>
Wrong window
<whitequark>
ok, looking at vqm
<ZirconiumX>
It's a monster, I realise.
<ZirconiumX>
:q
<ZirconiumX>
...I fucking did it again
<whitequark>
its a 1000 line file
<whitequark>
what am i looking at
<ZirconiumX>
It's a primitive netlist as a Verilog file
<whitequark>
.clk(\cd_sync:cd_sync|altclkctrl:$1|altclkctrl_07c:auto_generated|outclk ), what the fuck is this
<whitequark>
have they tried making it longer.
<ZirconiumX>
And *that* is why I told you to look at it
<whitequark>
does it still blink with 1 LED?
<ZirconiumX>
I looked at the diagram of the DE-10: it's the ARM core blinking the LED, not the FPGA
<emily>
maybe you should :q to sleep >.>
<ZirconiumX>
Sure, but whitequark can get drunk and I can't