/hard/ - Hardware General

[Anonymous No.1361784]

"Rolling the dice one more time" Edition

>What is hardware general?
Hardware general is a thread to discuss anything pertaining to the hardware side of technolo/g/y, be it computer architecture, data sheets for that new processor, low-level language design, robotics, server construction, or a cool make project; If its /hard/ it belongs on /hard/ware general. It has a sister thread on >>>/diy/ohm/. There is some overlap between the two but they differ significantly in their focus.

>---------------RESOURCES---------------<

>-----IC Suppliers:
Octopart (the google of IC) -> https://octopart.com/

>-----Custom PCB Producers:
DirtyPCBs - dirtypcbs.com
[for more see sticky]

>-----Tools:
Logisim (logic circuit simulator) -> http://www.cburch.com/logisim/
[for more see sticky]

>-----Other resources:
Digital Timing Diagrams: http://wavedrom.com/
Logic Table/Diagram/Expression: http://www.softpedia.com/get/Others/Home-Education/Logic-Friday.shtml

>---------------LITERATURE---------------<
"The Manga Guide to Electricity" - by Kazuhiro Fujitaki (a fun refresher)
"Fundamental of Electric Circuits" - by Charles K. Alexander and Matthew N.O. Sadiku
"The Art of Electronics" - by Paul Horowitz and Winfield Hill
"Digital Logic and Computer Design" - by M. Morris Mano
"Computer Organization and Design: the Hardware/Software Interface" - by David Patterson and John Hennessy
"Essentials of Computer Architecture - 2nd Edition" - by Douglas Comer
"Introduction to Embedded Systems: A Cyber-Physical Systems Approach - Second Edition" - by Edward Ashford Lee and Sanjit Arunkumar Seshia

Magazines - http://www.diagram.com.ua/english/library/#l5
IEEE Comprehensive Datasheet Collection - http://www.datasheets360.com/
[see sticky for full list]

>---------------STICKY---------------<
https://pastebin.com/gnSpHHHB

[Anonymous No.1361787]

>>1361784
if youre gonna flood the board with anime crap, you can fuck off right back to /g/

filthy rapefu/g/ees, they ruin their own board, then spread the same cancer around

[Anonymous No.1361796]

>>1361787
would this have been better?

[Anonymous No.1361806]

>>1361796
yes

[Anonymous No.1361828]

>>1361787
>implying we haven't had that same image as the OP for /ohm/

[Anonymous No.1361839]

>>1361787
kys

[Anonymous No.1361845]

>>1361828
That reminds me that I've never, ever seen another "artist's view" of a PCB which actually looks like a PCB.

[Anonymous No.1361847]

>>1361828
>ohm
where is this /ohm/ board you speak if?

[Anonymous No.1361852]

>>1361828
>>1361839
first they bring anime shitposts
then they bring trap memes "you code better if you crossdress"
then they bring the rest of the cancer

[Anonymous No.1361865]

>>1361787
>Complaining about anime on an anime imageboard

[Anonymous No.1361912]

>>1361852
>you code better if you crossdress
Is this real?

[Anonymous No.1361926]

>>1361912
it is a real meme on /g/ if that's what you want to know

[Anonymous No.1361953]

>>1361852
i like animeposting but i have to agree with anon that i don't want mentally ill trannies shitting up this board.

[Anonymous No.1363552]

bump. This thread has potential, despite a shitty start

[Anonymous No.1363556]

>>1361926
Fuckin Science !

[Anonymous No.1363557]

jesus christ get the fuck out you mentally retarded freaks

[Anonymous No.1363559]

normies dont belong here

[Anonymous No.1363866]

>>1363557
dont be mean anon

[Anonymous No.1364956]

I think these threads did better when they were on /g/, even if they last longer on /diy/. There's too much fighting and not enough hardware here.

I'm running icarus verilog sims and I've gotten to the point where I'd like to simulate some off-board communications. Is there a standard practice for this? What I'm thinking now is, I'll create an emulator unit that $fgetc's a named pipe, which I'll write to with some other program. Hopefully, that unit can get swapped with minimal extra code for synthesis.

The whole project is a neural net accelerator, which I'd love to talk about if anyone's asking.

[Anonymous No.1365303]

This could probably go into the SQT thread but:

I have an HS-422 servo motor that I want to control with arduino. The control signal is coming from the arduino, which is powered by a 9V battery. The servo is rated at 4.8V, do I use a voltage regulator like LM7805 to convert 9V DC to 5C DC for the servo?

[Anonymous No.1365309]

>>1364956
please tell me more about this neural net?

[Anonymous No.1365324]

>>1365303
>The servo is rated at 4.8V, do I use a voltage regulator like LM7805 to convert 9V DC to 5C DC for the servo?
doesnt that servo use 6v?

[Anonymous No.1365338]

>>1365309
See the text in the innermost circle.
It's just an oddly drawn LM337 schematic.

[Anonymous No.1365341]

>>1361784
>tfw no pick-and-place gf
i never asked for this feel

[Anonymous No.1365487]

>>1365309
The net itself isn't that interesting, it's basically a clone of AlexNet. For those unfamiliar, this is a convolutional neural network which does a pretty decent job classifying images.
We had to do some tweaking to make it work on 18-bit fixed point, because Xilinx RAMB and DSPs operate on 18-bit data, and floating point is difficult. There are some tools to do this (ristretto) without losing much accuracy, so it turns out the bit width isn't much of an issue.

The interesting bit is the accelerator hardware. Convolutional networks have a *lot* of parallelism, so we've got a bunch of systolic & SIMD bits to try to pull more performance out of the chip. Right now our goal is to run a classification every small number of milliseconds.

[Anonymous No.1365612]

>>1365303
First of all, can your 9V supply the ~160mA that the servo will take? The voltage regulator would be dissipating more than half a watt of power, but if you're ok with that then no problem go for it.

[Anonymous No.1365651]

>>1361953
>mentally ill trannies shitting up this board
why does this happen to every board i like?

[Anonymous No.1365840]

Thanks for keeping this up OP

I want to get into fpga's but not sure what to get? I did some vhdl with an fpga(don't remember the model). But I'm still pretty much a beginner
What would you guys recommend?

[Anonymous No.1366169]

Anyone here have experience with ASM?

I'm working on designing my own processor design and I wanted to run so ideas by someone with more experience.

Basically, I have two 8-bit accumulators, and I'm toying with the idea of an instruction to pair them up into a single 16-bit accumulator.

[Anonymous No.1366185]

>>1365840
The classic beginner board is the spartan 6. It's a bit small, but plenty for your first few projects while you're poking around.
Look for a dev board that has decent documentation and you should be good

[Anonymous No.1366211]

>>1366169
This is done pretty much always by having a bunch of "16b" instructions which operate on register pairs. Sometimes you can specify one of the used registers, sometimes the both registers are fixed.
It's simple and easy.

[Anonymous No.1366221]

>>1366211
Yup, I know that, but I'm talking about more than just simple data registers being paired up.

As for as I know, on most 8 bit microcomputers when a 16 bit number gets added, they do it in slices, one byte at a time.
I was thinking about taking the paired registers one step further and having paired ALUs.
Meaning you can either have two separate 8 bit ALUs, or a single 16 bit ALU.

[Anonymous No.1366421]

>>1361784
>The Manga Guide to Electricity
There's also one for Electronics.

[Anonymous No.1366493]

>>1366221
For each ALU, one input is an accumulator. The other is a mux that selects the 16b Hi byte or some other 8b register.

Do you know how you will handle the opcode(s) and extra registers?

[Anonymous No.1366510]

>>1366493
>For each ALU, one input is an accumulator. The other is a mux that selects the 16b Hi byte or some other 8b register.
Sorry, what exactly are you trying to get at here?

I have two accumulators and two ALUs, and the idea is to either have them work as independent 8-bit systems, or as a single larger 16-bit system.
When paired it would use 16-bit register pairs as the operands, or in independent mode they can each work independently using single 8-bit registers as their operand.

I haven't finished opcodes yet. I'm currently working on that part.
I'm not planning on any SIMD instructions currently.
Think of it like a z80 with two 8-bit accumulators that can be combined for 16-bit operations.
So I guess I'll wind up with 3 sets of ALU instructions. One for each acc, and one for the combined mode.
I'm still figuring that part out.

[Anonymous No.1366514]

>>1366221
If you have a de facto 16b ALU and 16b (internal) data paths, then the usual option would be to make the processor 16b and handle the 8b stuff as half-width operations.
I don't remember seeing a processor which would normally have two independent ALUs, with an option for cascading them. Also, usually two 8b ALUs together is slower than a dedicated 16b ALU.

[Anonymous No.1366525]

>>1366514
It started when I thought it would be nice to have two independent Accumulators, then I realized I could chain them together.
It also opens some interesting possibilities for SIMD, although I'm not planning on implementing that in this version.

I'm still working on how exactly all of the data paths will work. I really only just finished designing all of the individual components.
It's still a mostly 8-bit design, just with a few 16-bit extensions.

>I don't remember seeing a processor which would normally have two independent ALUs, with an option for cascading them
True, I'm kinda just doing my own thing here.
In the words of Seymore Cray: "One of my guiding principles is don’t do anything that other people are doing. Always do something a little different if you can."
>Also, usually two 8b ALUs together is slower than a dedicated 16b ALU.
Also true. Having two cascaded 8-bit ALUs will most likely be half as fast as a true 16-bit ALU.

[Anonymous No.1366530]

>>1363559
lets stop talking about this awesome pcb and make some ourselves

[Anonymous No.1366532]

>>1364956
you might be onto something with the fact that they did better on /g/

[Anonymous No.1366534]

I want to make a little led blinking pcb business card type thing and I want to keep my part count as low as possible. is it a bad idea to use 1 resistor for 2 leds in parallel?

[Anonymous No.1366540]

>>1366525
Going against the conventional wisdom won't make you the next Cray. Particularly if it's your first design.

More importantly, what do you want from us? You asked if anyone here has any experience on asm, which implies using the existing processors, not oddball experimental ones.

[Anonymous No.1366565]

>>1366540
>Going against the conventional wisdom won't make you the next Cray
Obviously. But I'd rather not make yet another 8080 clone.

>More importantly, what do you want from us?
I want input from people with more experience as to if they would use such a feature or not.
My goal is to make an architecture that is fun an easy to use.
I only know z80 ASM, so I don't have a whole lot of a diverse experience to base this on.

[Anonymous No.1366602]

>>1366565
>I only know z80 ASM
Did you care about the fact that the Z80's ALU does addition in 4b pieces? I didn't, I didn't even know it then.
I don't really care how the processor does its shit internally. What I do care is how it is presented to me. In this sense, I'd rather have the processor to have "16b" instructions for operating on 16b data, without obnoxious side effects and limitations. I'd rather not micro-manage your two ALUs (execution units?) and I would hate setting/resetting mode flags to switch between the 8b and 16b modes. Of course, you can mask some of that by using macros, but still.

Well, it's your toy. You should do what you find more interesting.

[Anonymous No.1366701]

>>1366602
>Did you care about the fact that the Z80's ALU does addition in 4b pieces?
No, but that's not the point.

I'm asking: If you had a processor that could switch between having two 8-bit accumulators, or a single 16-bit accumulator, would you take advantage of that, or would you just peg the thing to 16-bit mode and forget about it?

You're not micromanaging anything, you just get the choice of having two accumulators, or a single larger one.

[Anonymous No.1366706]

>>1365612
I wonder if submarine anon ever made it out on the Great Lakes like he planned.

[OP No.1366730]

I'm liking the activity in this thread rn.
I've heard some anons asking that i move this back to /g/ but i think that /g/ is not the place for it since its a slower thread (what with it not being as accessible as koding is). I
'll keep it on hard for a while and then either try /g/ one more time or try my hand over on the 8th channel.

[Anonymous No.1366743]

>>1366530
But is that a PCB with components on it?

>>1366706
Yeah, those were good threads. At least bunkerbro shows up every month or two.

[Anonymous No.1366880]

>>1366701
Point was: I'd pick the option with least hassle. Unless your 16b mode is too slow, wasteful, inflexible, idiosyncratic or otherwise bad for general use, yes, I'd keep the processor in its 16b mode, except maybe for some special cases. In case there's some significant penalty for using it, I'd prefer the switch to require as little effort as possible.

If you don't give the programmer full control over the other ALU, does it mean that it sits unused in 8b mode?

[Anonymous No.1366884]

>>1366743
Working on it

[Anonymous No.1366891]

>>1366880
The programmer does have full control over the other ALU.
Each ALU only services a single accumulator, so each ALU gets used when it's respective accumulator is used.
They could also be used in tandem for SIMD, but I'm not planning on that for v1.

[Anonymous No.1366909]

>>1366891
The way you put it makes me assume that the difference between instruction OR R0, 123 and OR R1, 123 is just that the first uses ALU0 and the second ALU1. If you can't run them in parallel or specify different simultaneous instructions for the separate ALUs, then the fact that there are two ALUs is invisible and irrelevant to the programmer. Well, unless the processor has two sets of flags, which sounds like a pain in the ass.
Did I get something wrong?

[Anonymous No.1366940]

>>1366421
Got a link for electronic circuits one?
The manga guide to electricity honestly helped me get my head around electricity.

[Anonymous No.1367321]

>>1366940
I tried to deliver, but for some reason there isn't an english version (looks it was cancelled). The best I could find was a sample chapter in HUE HUE BR:
https://s3.novatec.com.br/downloads/amostras/amostra-manga-circuitos-eletronicos.pdf

If you're interested, there's one on microprocessors:
http://50.116.28.134/MangaGuidetoMicroprocessors.pdf

[Anonymous No.1368593]

Is it possible to create a hard-ware level spoof for TCP and IP?

[Anonymous No.1368596]

>>1368593
Certainly, but not easy. Is something done with FPGAs/CPLDs/microcontrollers good enough for you, or did you want to go full 7400 series?

[Anonymous No.1368613]

>>1368596
whichever one is 1337er

[Anonymous No.1368622]

>>1368613
prepping your anus for defcon?

[Anonymous No.1368625]

>>1368622
nope, just interested.
What's defcon?

[Anonymous No.1368635]

>>1368625
yearly hacker/nerd convention in vegas

[Anonymous No.1368641]

Would anyone happen to have a pdf of "Computer Architecture" by Caxton Foster?

I've been looking high and low and all I can find is a shitty DRM'd audiobook version and a Spanish translation.

[Anonymous No.1368642]

>>1368635
What do they do?

Also please tell me more on how to spoof TCP with FPGA?

[Anonymous No.1368648]

>>1368642
No clue how you'd do it, but you can do pretty much anything discretely provided you have enough gates. Start with a big fucking truth table?

[Anonymous No.1368653]

>>1368648
How into complex multidimensional truth tables?

[Anonymous No.1368655]

>>1368642
use an fpga dev board with two ethernet PHY transcievers and rewrite packets with spoofed addresses.
I think you are more than "just interested", you sound like the script kiddies who used to go on irc and ask actual programmers how to compile exploits. the answer is git gud.
what do you even know about tcp, networks, programming, or digital logic?

[Anonymous No.1368656]

>>1368655
>you sound like the script kiddies
sad to say i pretty much am

>tcp, networks, programming, or digital logic?
programming? 4 lang's and counting.
TCP? vague notions.
Networks? jack shit but i'm teaching myself online with videos and soon pirated books.
Digital logic? The basics, like how to make a full adder, half adders, a JK-flipflop counter, etc.

[Anonymous No.1368677]

>>1368653
Multidimensional? Just add columns and rows until you have enough. Perhaps you can write a code that processes a CSV as a truth table and gets you the SOP and POS results, if something doesn't already exist for n*m truth tables. I know logisim has something along those lines, but I think it's limited for single output and limited in dimensions. I might python myself one of those csv converters one day.

[Anonymous No.1368680]

>>1368677
i'll put that on my todo list then...

[Anonymous No.1368689]

>>1368656
once you learn networks you'll then learn why spoofing TCP addresses is pointless

[Anonymous No.1368692]

>>1368641
Anyone? Please?

I've got a stash of computer engineering pdfs that I'll post if anyone can find this.

[Anonymous No.1368710]

Can anyone recommend textbooks for digital electronics? Particulary focusing on things like cmos logic, transistor sizing, synchronus and asynchronus signals, setup time, hold time, and propagation delay, metastability, and verilog, if possible

[Anonymous No.1368811]

>>1368710
I've done some synchronous and asynchronous signals and a little propagation delay in my entry-level textbook, Digital Fundamentals, but I doubt it's got what you're looking for in general.

[Anonymous No.1368960]

>>1368811
>Digital Fundamentals
Yes, that book is below the level I'm looking for. Thanks though

[Anonymous No.1369024]

>>1361784
Are PLCs and Automation relevant to this?

[Anonymous No.1369063]

>>1361784
ok /hard/ what image should I put on the back of my nixie power supply pcb?

[Anonymous No.1369088]

>>1369024
VERY

[Anonymous No.1369137]

>>1368710
http://libgen.io/search.php?req=digital+electronics&lg_topic=libgen&open=0&view=simple&res=25&phrase=1&column=def

>go hog-wild

[Anonymous No.1369156]

>>1368710
My school uses Michael Ciletti books. But I didn't read mine, so I can't tell you how good they are. Lectures and experimentation were more helpful.

[Anonymous No.1369364]

Can anyone explain why 64k x 8 SRAM is seemingly non-existent?
All I can find is expensive ass dual-ported SRAM in that size.

I'm working on a simple TTL VGA adapter, and I'd like to be able to do 320x200@8bpp, which is exactly 64000 words.
I mean, I guess I could get 128k x 8 SRAM, but that just feels wasteful, since I'll only be using half of each chip.

[Anonymous No.1369405]

>>1369063
A squatting slav, or Stalin, or maybe a shipping container instead.

[Anonymous No.1369416]

>>1369364
well you can double up one of the address pins to use the whole chip if you're worried about wasting space. HAR HAR i make joke.

[Anonymous No.1369460]

>>1361852
>"you code better if you crossdress"
is this true?

[Anonymous No.1369465]

>>1369364
Manufacturers prefer roughly square memory arrays, meaning (8b wide) chips with odd number of address lines.

Ye olde solution would've been using two 32kB memories. Too bad that option costs more nowadays.

[Anonymous No.1369466]

>>1361926
/g/ is a filthy consumerist board. the most creative thing they can achieve is installing some linux distro. i hate those normfags

[Anonymous No.1369471]

>>1369364
being able to do dual buffering would be a handy feature, or 640x200/320x400, or 16bpp.

[Anonymous No.1369476]

>>1366701
that depends. if your faux 16bit mode isn't considerably slower I'd just stick to that and use the 8bit mode only if performance required it.
but I think you're asking the wrong questions here and try to deal with problems you think you might have. how about you get your 8bit cpu finished and worry about 16bit for your next project?

[Anonymous No.1369478]

>>1364956
What's your simulation setup right now? What I usually do is create modules (plus a shitload of bloaty classes for muh abstraction) in Systemverilog that interact with my model under test. That way, off-chip and off-board comes out to the same thing.
With SV it's very easy to get carried away though so try to define in advance what your functionality should be.

[Anonymous No.1369480]

>>1368642
spoofing tcp is easy in theory: just guess the right sequence number and make sure your packet reaches the destination faster than the original one

[Anonymous No.1369491]

i need some pdf to learn the basic of the hardware

[Anonymous No.1369661]

>>1369471
Dual buffering is a good idea.

Actually, I think I'm going to need to use dual port RAM anyways.
I haven't got any sprite hardware set up, just a blitter.
I don't think I'll be able to rely on just DMA during vblank to update the whole screen.
Unfortunately, that means I'm going to need to move the VGA adapter into a FPGA, because that'll add $120 to the BOM in DPRAM alone.

[Anonymous No.1369669]

>>1369063
it is gonna be a nichijou crow

[Anonymous No.1369670]

>>1369669
and a unicorn

[Anonymous No.1369752]

>>1369460
no, but it is gay.

[Anonymous No.1369753]

>>1369480
what about spoofing IP though?

[Anonymous No.1369754]

>>1369491
<--

Also question for the thread: what is the best switching fabric?

[Anonymous No.1369764]

>>1369752
Will being gay help me code better?

[Anonymous No.1369781]

>>1369764
probably not but combine it with hipster faggotry and it will help you get payed more.

[Anonymous No.1369820]

>>1369781
>>1369764
Also get your dick chopped off and dye your skin black.

On top of that, be the most obnoxious faggot you can possibly be and ruin every project you touch.

[Anonymous No.1369845]

>>1369820
Can I keep my balls though?

[Anonymous No.1369895]

>>1369661
I just redid the design so I won't need dual ported RAM.

Tell me if this looks retarded, ok?
So basically I have two layers, a background and a foreground, and each is double buffered.
Each pixel is a full byte: 2 bits per color channel, and a 2-bit blend mode attribute.
A simple ALU (more of just a logic multiplexer though) blends the two layers and then that gets passed to the DAC.
A single blitter is responsible for both layers, and only works on the buffer not being displayed.
The blitter really only moves blocks of memory. I might give it the ability to flip bobs horizontally and vertically, but right now it just does translation.
Not shown is the address lines. I kinda ran out of space for those.
I also need to make a circuit to translate V and H count into memory addresses.

For the blend modes I have:
>Opaque
>Transparent
>XOR
>Undefined
Obviously, only the second layer can utilize these.
Also, what would be a good operation for the undefined blend mode?
I couldn't come up with anything. Add?

[Anonymous No.1369922]

>>1369845
No, those are the first to go.

[Anonymous No.1369932]

>>1369478
It's actually straight verilog 2001, not systemverilog.
I did end up using the fgetc, though for some reason it breaks on a named pipe.
My standard thing is I'd do as you describe -- write some test bench modules that manage a bunch of input signals. This case is interesting, though, because I want to test interaction with a C program that's the other side of the accelerator. I imagine that when I synthesize Xilinx will give me some nice standard interface via to their AXI protocol. So, I've got a module on the verilog side that pretends to be an AXI3 input but really reads from a file, and a library on the C side that pretends to be an AXI3 output but really writes to the file.
This is very much a hack. There's something called "SIMBUS" that I think claims to do what I want. I might try that, but I'm generally reluctant to add dependencies.

[Anonymous No.1369948]

>>1369845
balls are a sign of rape culture you shitlord, you'll need to lop em off :^)

[Anonymous No.1369953]

>>1369895
OP here, just wanted to say that this post is exactly what these threads were made for and i love that this post exists.

Best of luck with your bi-layer buffer anon, i look forward to the finished product!

[Anonymous No.1369958]

>>1369953
Glad to hear that!

Hopefully I can get something usable working.
I've never done anything like this before.
I feel like it would work, but I can't help but think that I'm using an absurd amount of RAM for what it's doing.

[Anonymous No.1369963]

>>1369958
>I've never done anything like this before.
the first step in any journey is to try something you have never done before, i myself plan on learning a new spoken language and getting intimately acquainted with the linux kernel.

For the memory access btw i would recommend two multiplexers? demultiplexers? (whichever one splits a signal into many signals) that takes the H and V count as input either independently or together, dependent on your intended design. Alternatively you could use an MMU. For the moment i would recommend seeing if you can get it to work first in practice before you try an optimizations.

[Anonymous No.1369973]

>>1369963
Could you elaborate on the multiplexers?
I've just been thinking of making a circuit that adds H count and V count together to create an address, and that would go through a mux that directs it to the active buffer.
Meanwhile the blitter gets to do whatever it wants with the inactive buffer (going through that 4:1 mux).

Two things I haven't really decided on yet is how the framebuffer will be layed out in memory, and how exactly the blitter will function.
I'll be honest, I'm used to sprite based systems, so blitters are bit foreign to me.
I'd go for a sprite based system, but blitters look easier to implement.

[Anonymous No.1370052]

Is it just me or is pipelining a super sexy presentation of parallelism?

[Anonymous No.1370137]

I bought a bunch of RC cars from goodwill yesterday to harvest the electric motors
not sure what I'll do with them but I'll figure something out. I'm hoping they'll be a bit higher torque than, say, a fan motor

[Anonymous No.1370183]

>>1368641
>>1368692
Try http://gen.lib.rus.ec/
Search using the isbn 10

[Anonymous No.1370197]

>>1370052
it's pretty sexy. assembly lines applied to microelectronics.

[Anonymous No.1370271]

I don't know if any of you guys circuit bend, but for those who do

Now that most toys are SMT with epoxied bare silicon chips, it's much harder to bend them
I've just realized I can scrape the paint off of the traces leading into the chip so I wouldn't have to delid it

my problem is, how can I solder anything to a bare trace? Lots and lots and lots of flux and a thin solder tip?

[Anonymous No.1370361]

>>1369973
I was wandering if you could elaborate on what exactly you intend to do with this device? I'm still a bit unclear on your intended goal.

For the H and V count, do you plan on using the sum of both to address? and if so do you plan on doing it with logic or an ALU? I would not recommend modifying inactive buffers unless its to reduce instruction execution time and you know what you're doing.

You could also use an in-built cache set up specifically for the buffer independent of system memory, and then you can flush the cache after every operation cycle to keep things clean. Whatever you choose for memory should be: fast read/write, no bigger than necessary, and contiguous memory, possibly also transparent if its intermediate.
BTW, how many bytes do you intend each buffer to be? And what do you intend the buffer to be made out of?
I'm unfamiliar with blitters so i don't know what to say about them or recommend.

[Anonymous No.1370433]

>>1370361
The goal is to make a simple VGA graphics card for 8-bit microcontrollers or computers.
I'll probably drive it with a z80 or something like that.
I just like old computers and demoscene stuff, and since I'm a computer engineering major I thought I'd take a crack at making my own retro computer.

>For the H and V count, do you plan on using the sum of both to address?
Basically. It'll be a bit more complex than that though because every combination of H and V count needs to translate to a single unique address.
>do you plan on doing it with logic or an ALU?
Probably just a simple adder and some hardwired shifts. Still figuring out that part though.

>I would not recommend modifying inactive buffers unless its to reduce instruction execution time and you know what you're doing.
Huh?
I can't write to the RAM while it's being read from to the screen. That's why I have two frame buffers.
One to modify and write to (the inactive buffer) and a second one to be read from and rendered on screen (the active buffer).

>how many bytes do you intend each buffer to be?
64kbytes. That's just enough to store a 320x200x8bbp framebuffer.
Also because 64kbytes is the most ram I can address with a 16bit address bus and not need bank switching.
>And what do you intend the buffer to be made out of?
SRAM. Just plain old 64k x 8 SRAM.
I'll have 4 of them. Two per layer (double buffer), and two layers.
Although I'll probably wind up with 128k * 8 SRAM, just because 64k * 8 is pretty much non-existent.
I could eliminate the double buffer by using dual ported SRAM, but that's WAY too expensive.

Blitters are a piece of dedicated hardware who's job is to move chunks of memory around quickly.
They often have a few bitwise functions like AND, OR, XOR, and sometimes have special functions like bucket fill or the ability to draw lines or other shapes.
Mine will just do simple memory block transfers, although I'm trying to work out exactly how to do that.

[Anonymous No.1370617]

>>1370433
You know what? I'm just going to drop the blitter.
I haven't come up with a good way to interface with it so far, and half of what a blitter traditionally does has been offloaded to the layer blender anyways.

The dual buffers and hardware layer blending lighten the load enough that using the CPU to drive it probably won't be too much of a problem anyways.

I'm also going to drop the resolution to 256x240, that way I can address every pixel with just two bytes.

[Anonymous No.1370621]

>>1370617
Sounds good. Z80 and similar systems generally wouldn't use a blitter anyway, just direct RAM access maybe with sprites and/or a font ROM for text mode.

Keep in mind the addressing abilities of your CPU, Z80 has a 16 bit address bus/64KB address space, so you'd want to 32K per buffer or below so that you've still got a decent amount of address space for system ROM and RAM

[Anonymous No.1370689]

>>1369932
>straight verilog 2001
OK so my advice would be to abandon that shit ASAP, especially for testbenches. If you prefer old school verilog for the hardware design, I guess that's legit but for testbenches you're just shooting yourself in the foot.
You can also call C functions from SV somewhat easily so that might help too.

[Anonymous No.1370745]

>>1370621
Unfortunately, this card design is really RAM hungry.
It's going to use just under 64k, so I guess I'll have to multiplex the bus.

Framebuffers take up so much memory!

[Anonymous No.1370753]

>>1370745
Which is why Z80 and similar systems generally didn't use such big framebuffers. CPC, MSX for example only used 16KB

[Anonymous No.1370761]

>>1370753
I know, but sprites and tiles are harder to implement.

[Anonymous No.1370790]

>>1370761
CPC and MSX didn't have sprites or tiles either.

[Anonymous No.1370801]

>>1370433
>Probably just a simple adder and some hardwired shifts.
Instead of doing that, you could have your address counter going from 0 to 320x200-1 and then have another counter (0 to 319) synchronized to it producing the H-syncs. It doesn't really matter with an FPGA, but I think you mentioned TTL at some point.
Also, 30FPS sounds rather low. What kind of monitor you have?

>One to modify and write to (the inactive buffer) and a second one to be read from and rendered on screen
Graphics is pretty taxing for typical 8b processors and this tends to increase the workload of your processor.

[Anonymous No.1370851]

>>1370433
This sounds pretty generically useful, actually. When I'm doing VGA shit on an FPGA I'll generally write my own VGA buffer, but it's really a resource hog.
I'm not sure if this is the same as your project, but having a special chip just to handle the standard implementation sounds pretty nice.

[Anonymous No.1370853]

>>1370689
>export "DPI" function write;
Godammit, this is exactly what I wanted. Thanks for the tip.

[Anonymous No.1370869]

>>1370790
I though the MSX had support for 32 sprites, 4 per line.

>>1370801
>have your address counter going from 0 to 320x200-1 and then have another counter (0 to 319) synchronized to it producing the H-syncs
Yeah, That's basically what I have.
Actually, by reducing the resolution to 256x240 I'm able to just have the H counter go to the lower 8 bits of the address, and the V counter on the upper 8 bits.

>30FPS sounds rather low. What kind of monitor you have?
It's more of a pseudo 30FPS.
The output will run at 60FPS, but it'll only swap buffers every second frame, that way the CPU has more time to work on the framebuffer.

>Graphics is pretty taxing for typical 8b processors and this tends to increase the workload of your processor.
Yeah, which is why I originally planned to include a blitter.
That would significantly alleviate the work required to be done by the CPU.
Still though, since I have two layers with hardware blending, I think that will reduce the load enough that a 8-bit CPU could drive it.
The second layer means that the CPU doesn't need to redraw the entire framebuffer every frame, nor will it have to do any bitwise operations.

[Anonymous No.1370881]

>>1367321
Not that guy, but thanks.

[Anonymous No.1371054]

Have there been any benchmarks for ryzen 2000 yet?

[Anonymous No.1371063]

>>1371054
What kind of benchmark we talking?
whetstone? dhrystone? odds? software?

[Anonymous No.1371072]

>>1370851
Good to hear that.
I think there are some chips out there already that will handle the buffer and VGA generation, but they're all black boxes and kinda pricey.

I'm planning on documenting this well enough for anyone to learn how it works and make their own.
I'll probably have a vhdl file for it available for download as well.

[Anonymous No.1371084]

>>1369754
i would like to know this as well, to speed up my shitty MIMD pentium system.

[Anonymous No.1371388]

>>1370853
DPI is a blessing and a curse. You can do some pretty neat shit (I use it to collect responses from my framebuffer/text reader device model and store them in a framebuffer, which takes all of like 10 lines and makes it possible to write bitmaps of the images my thingy outputs) but simulator support is a bit spotty and debugging it is usually a mess. Make sure the C functions you call fail noisily otherwise you can get stuck in debug hell really easily.

[Anonymous No.1371470]

I have a project for school that has to use a pic microcontroller to do something. I can't think of any good ideas and thought you guys might have something neat to consider.

Thanks

[Anonymous No.1371473]

>>1371470
this question gets asked every week, all the cool ideas have already been done.
alright here's one. game of pong or asteroids but with a laser projector and mirror controller.

[Anonymous No.1371517]

I would like to share with you all that I have a Craftsman brand rotary tool and the Dremel brand diamond cut off wheels work with it. I can't say that I know much about this stuff but maybe it is useful information to someone.

[Anonymous No.1371536]

Does anyone know where I can get extra excersises with answers for computer design and organization?

[Anonymous No.1371549]

I bought this OV7670 Camera module from Aliexpress that says it has an AL422B FIFO on it - are they full of shit? I don't see it in the photos. I'm hoping it's on there and I'm just retarded.

https://www.aliexpress.com/item/OV7670-VGA-Camera-FIFO-Buffer-AL422B-module-640x480-0-3MP-CMOS-I2C/32818140993.html?spm=a2g0s.9042311.0.0.pOfF7G

[Anonymous No.1371573]

I was given a ZTE Open mobile, along with its normal Firefox OS.

I don't really need it for anything and apparently it has an exploit. Is Firefox OS any good? Is it worth changing to Android.

[Anonymous No.1371609]

>>1369895
unless you're intentionally interlacing I'd probably allow the programmer to choose when to switch the buffer, or even to allow host access to the visible buffer, using some wait state generator to prevent access during scanning, or just saying fuck it and allowing access during scanning (CGA snow, woohoo)
also, consider DRAM, you can use burst modes to slam 8 or 16 words at a shot into a FIFO ahead of the video pipeline, and it's a hell of a lot cheaper. in case you don't have DRAMs with auto-refresh, the address counters could do the refreshing for you. advantages: with a larger RAM you can do vertical scrolling or multiple-buffering just by adjusting the display start address, and by grabbing words into a FIFO you free up time for host access to display memory, making the double-buffering optional
>undefined blend mode
how about add?

>>1370761
on an FPGA, they should be quite easy though. you just define a single sprite unit with whatever config registers, a pixel-in, and a pixel-out, and instantiate as many as you like in the pixel pipeline

>>1370869
a rectangle copier is enough to call a blitter. it's basically just a few counters and flip-flops, and you don't even have to make the register map all that "nice". it would make a nice addition for v2

[Anonymous No.1371629]

>>1371609
I'll admit, I'm not that familiar with interfacing with DRAM or using burst modes.
I'll look into that.

Also, I'd agree about letting the programmer just switch the buffer whenever they feel like it.
That would also open up the ability to perform parallax like effects by switching buffers mid frame.

>on an FPGA, just define a single sprite unit with whatever config registers, a pixel-in, and a pixel-out, and instantiate as many as you like in the pixel pipeline.
Would each of those units be like a layer, or do the each handle a single sprite each?


On the subject of the blitter:
I couldn't really think of any nice way to interface with it.
Ideally I wanted to give it some kind of instruction FIFO, that way the CPU could just give it a set of tasks and then fuck off to go back to computing.
But I couldn't think of any good way to do that.
I mean, I need to give it an address for where to transfer from, and a address for where to transfer to, and then there's the question of if I want to have a fixed rectangle size it will transfer, or be able to specify it.
So that there is 4 bytes of memory needed to specify a single blit, at minimum, and I've only got a 1 byte bus to work with.
it gets more complex when I start thinking about having a character ROM for it to use for text modes.
So yeah, I think I'll save the blitter for v2, when I've got some more experience under my belt.

[Anonymous No.1371652]

>>1371629
DRAM is good if you're not going to use discrete 74xx logic to implement it. it's hard to find slow DRAM these days though
>That would also open up the ability to perform parallax like effects by switching buffers mid frame.
right, even split-screen effects with smooth and fast vertical and horizontal scrolling without actually moving any video data around. more mundanely, since you have shitloads of memory with a DRAM, you could also widen your viewport back up to 320 pixels onto a 512-wide buffer and just add an offset from a register to the x part of the address
>Would each of those units be like a layer, or do the each handle a single sprite each?
yes, as sprites are usually designed to layer over one another in priority order
each layer in that pipeline potentially consumes time, so if you have a large number of sprites that may not be the best design. but outside of games it's rare to need more than one sprite, for the cursor, whose data could even fit inside the FPGA without consuming extra memory cycles, and even then if you have layered framebuffers the blitter can probably do it better without adding extra logic in the pixel pipeline
>Ideally I wanted to give it some kind of instruction FIFO, that way the CPU could just give it a set of tasks and then fuck off to go back to computing.
practically speaking, a blitter done interrupt might be enough. the host is probably better equipped to manage a list of blitter ops intelligently. if you really wanted to get wacky you could implement DMA between the host and blitter registers or video memory. I'd wait for v3, kek
>1 byte bus
but you're just loading registers in a predetermined order, which the host would see as 1 byte wide anyway. in any case you can have as wide a bus as you like inside the video system, indeed, x16 DRAMs are commonly available. don't forget that all but the smallest FPGAs have block RAMs scattered throughout, which are good for FIFOs, sprite storage, etc.

[Anonymous No.1371655]

>>1371629
also, on-board RAM in the FPGA would be good for a character/tile generator, but text modes get a bit hairy and don't share too much logic with the bitmap stuff. maybe a very simple blitter that just copies tiles from that on-board RAM into one of the planes would be enough. you could make it parse ASCII control codes or, for maximum lulz, VT100 escape sequences

[Anonymous No.1371663]

>>1371652
>>1371655
Good info, thanks!

[Anonymous No.1371665]

>>1371629
finally, I would suggest looking to the Amiga custom chips for inspiration. they did a lot with surprisingly little.

[Anonymous No.1371717]

>>1371470

[Anonymous No.1371742]

What is the best processor for mining CryptoCoin?

[Anonymous No.1371855]

>>1371665
Any good documentation for those?
I've been looking at them, but most of the information I've found has either been hardware specs. Nothing really related to how they work.
Honestly, the thing I want to work on the most is reducing the memory footprint.
Since I'm addressing every pixel individually, the 256x240 window takes up 60kb of memory.
The obvious answer is to drop the palette size, but I kinda want to keep my 64 color 6-bit RGB.
I guess this is where the blitter would come in handy, since that would let me separate the VRAM from the rest of the system bus.

Also, how do you connect multiple memory chips into a single linear address space?
I found this online, but I'm not sure that I fully understand it.

[Anonymous No.1371878]

>>1371855
>Honestly, the thing I want to work on the most is reducing the memory footprint.
>The obvious answer is to drop the palette size,
I'd say the most obvious answer would be to use a processor with bigger address space.
You could also use banking, or enter the pixel addresses via registers.
The old EGA/VGA used an odd system where the video memory appeared as monochrome (reducing memory footprint) and then you had a separate register for selecting the bit planes (=colors).

>I found this online, but I'm not sure that I fully understand it.
Most of it is just Z80-specific shit or needed to support two different memory sizes. Basically you connect all your memories in parallel (addresse, data, r/w, oe) and then use the individual CS lines to activate one of the memories as needed. If your memories have, say, 13b addresses and you use a 3-to-8 decoder like 74138 to convert the next 3 address bits to 8 chip selects, then you'll have a contiguous memory of 64kB. Not that all the memories have to be of the same size, but if they aren't, you'll get repeated blocks. That is, if one of the memories is 2kB, you'll see it repeat 4 times in its 8kB window.

[Anonymous No.1371885]

>>1371878
>I'd say the most obvious answer would be to use a processor with bigger address space.
True.
My target is 8 bit systems though, because I also want to make a TTL CPU later on.
I was actually working on a TTL CPU before the VGA card, but I got stuck at instruction encoding.
That's when I decided to do the graphics card first since that's just a bunch of memory and counters.

>You could also use banking, or enter the pixel addresses via registers
Also true. I just would rather avoid that though since I don't really like having to work with data structures that span across multiple banks.

Thanks for the cleaner diagram. It makes sense now.

[Anonymous No.1371991]

guys I'm struggling to get into this stuff without direction, just reading about how components work is rather dry. sorry if this is more /ohm/ than /hard/ but can people suggest simple low voltage projects to work towards.
as it turns out a full blown college physics curricula doesn't include anything more complicated than resistors, capacitors and solenoids. I used a mosfet once, literally just to show how the output works, it wasn't even doing anything.

[Anonymous No.1372024]

>>1371991
>a full blown college physics curricula
Sounds like they didn't have any network theory, BJTs, or opamps, which is what a few physics papers at my college have. One about digital logic too. As I do with any project, I just look up how things work as I go, and usually end up with something efficiently designed that works. But for that you need a project. I'd recommend starting with /ohm/-tier analog stuff as it will give you a basis for understanding digital circuits (things like pull-ups, how different logic families work, etc.), so maybe something audio-based, perhaps one of those infrared audio senders everyone was talking about a few threads back on /ohm/, or a class-D amp. Other ideas are a non-contact voltage detector, coil gun, torch, or anything in >>1371717 that strikes your fancy. Chances are you'll want to enter the realm of microcontrollers sooner or later, but I don't recommend starting with them for the aforementioned reason(s). For the most part electronics is about piecing together individual building blocks (amplifiers, filters, multiplexers, counters, decoders, ADCs, clocks, etc.), so just getting variety of projects under your belt will teach you a lot about a handful of these building blocks that you can later use to design your own circuits. Radio stuff is also pretty interesting, though it is a pretty large rabbit hole.

[Anonymous No.1372062]

>>1371855
you can probably find Verilog implementations of the custom chip sets around, but I was thinking more of top-level features. e.g. the Copper was a very simple coprocessor tightly integrated with the video system. it had three instructions: wait for beam position, skip if beam position passed, and write a 16-bit value to custom chip register. e.g. HAM mode (below)
>memory footprint
the 80s dudes had many ways of selecting from a large palette of colors with relatively few bits per pixel. C64 used the text attributes to determine background and foreground, with the option of doubling the pixel width to select from global colors in video registers (all of a fixed palette of 16). the Atari ST's low-res mode simply used 4 bits to select from a 16-color palette (of 512). the Amiga did much the same and added a hold-and-modify mode, in which the 2 MSBs of a 6-bit pixel would replace one of the previous pixel's three primary colors with the 4 LSBs, or fetch all three primaries from the palette (of 4096) indexed by the 4 LSBs. consider that, with a Copper-like coprocessor, you could install a new palette every scan line and get plenty of color, maybe even expand to 9-bit or 12-bit color
look at it this way: 320x200x6 is never going to equal much less than 384000, and the harder you try to pack the address space, the more complex the address generator's going to have to be
if not banking, how about 8088-style segmentation? that's just a register and an adder
>connect multiple memory chips
you gate the chip's chip selects with the bits of the address too big for the individual chips to handle. or, if you'd prefer a wider array (so that you could read out multiple bytes at once, say, because your RAM is slow or you want to free up more cycles for host access) you use the low bits to drive the 3-to-8 decoder, and hook busA3 to chipA0, busa4 to chipA1, ..., busAx to chipA(x-3)

[Anonymous No.1372230]

>>1371991
>>1371717 and pic related.

[Anonymous No.1372478]

>>1372230
Don't teach electronics with micros first. You need an understanding of the physical limitations of your digital components before you start whacking shit together. Things like pull-ups, input and output impedances, frequency responses and parasitics, and linear/saturated transistors. Starting with digital logic is one thing, but with arduino you're not even going to be mentioning propagation delay, synchronous and asynchronous circuits, logic families, or nyquist rates. Just lines of code and wondering why your circuit doesn't behave as it should.

[Anonymous No.1372490]

>>1372478
And once you get into micros, be sure to learn how to use interrupts.
If you're not using interrupts (where applicable), then you're barely using half the tools that microcontrollers provide to you

[Anonymous No.1372495]

>>1372478
you seem to know your shit then, why don't you recommend for that annon?

[Anonymous No.1372496]

what's the bump limit here?

[Anonymous No.1372500]

>>1372495
I did:
>>1372024

[Anonymous No.1372518]

WEW

Dropped this vox dynamic looper pedal last year and I've been in a a few times to look for anything that stands out, still can't find anything. Does anyone have any tips?

There are 3 boards: power and plugs, tiny expression pedal board, and the big main processing and buttons board. I get power but I get all red lights which is a "return to vox to get repaired" condition. I can start it in factory reset mode, which after some button holds and presses does print a successful initialization, but then it returns to all red lights.

I can't find any cracks or burned out components, nothing looks out of place. There is no support for this or anything online but I don't want to scrap it

What is your experience with drops?

[Anonymous No.1372527]

>>1372518
A component might have had a solder joint come loose.

Not much you can do about that without a hot air rework system.

[Anonymous No.1372528]

>>1372518
Broken solder I'm guessing. Check the solder of the large components (pots, buttons, large caps, sockets, switches) to see if there are hairline cracks through it. Don't be afraid to torque them a little to see if a crack opens up. Reflow any suspect joints.

It might be a clone of a model that does have online documentation though I don't have a clue how you'd find that out. Chances are it's something integral to the board, otherwise it would boot fine but produce incorrect results if it was a filter cap or something. So I'm guessing it's the pots, especially as they interface with both the enclosure and the board.

[Anonymous No.1372733]

>>1372528
>>1372527
I'll check the pots thanks

[Anonymous No.1372760]

>>1372518
could also be broken crystals running out-of-spec. might want to examine all those QFPs with a microscope and see if any solder joints came loose. a pencil iron with a fine tip and some liquid flux should be enough to repair any loose connections
also make sure no buttons are stuck ON

[Anonymous No.1373067]

>>1365487
It fucking simulates. Thank god, now the work is writing the driver and getting it to synthesize.
That can't be too hard, right? (joking)

[Anonymous No.1373226]

>>1373067
Can you explain what this is doing, i'm not exactly an AI researcher or anything.

[Anonymous No.1373438]

>>1373226
There's was actually an off-by-one error in that image, but it was easy to fix.

Short of it is, it's doing a bunch of multiply-accumulate and writing it back to memory.

Long explanation is that it's doing a convolutional neural net operation. There's a graphic that shows it pretty well about halfway down the page at http://cs231n.github.io/convolutional-networks/
This kind of network is good at recognizing things in images, so that's what we're hoping it will do.

It's not that impressive to do this sequentially, but we've got a bunch of tricks that makes the whole thing more parallel (systolic arrays, and a data broadcast system that I don't know if it has a name). Google's got a custom chip ("TPU") that does the same thing but in a more general way.

[Anonymous No.1374320]

I am >>1372518 I couldn't find and solder breaks, but hotspot is the largest QFP in that pic. Would this temp indicate a broken chip?

[Anonymous No.1374509]

>>1374320
Well, that large chip is the Digital Signal Processor, so it probably will be generating most of the heat.
But 107ºC is a little hot. Actually, that's really hot.
I'd check it out.

[Anonymous No.1374514]

Can I get some input on bus design for a TTL computer?

I can't decide between a mux based system bus or a tri-state system bus.
Originally I was thinking about using a mux base design, but now that I've read more about using tri-state logic, that seems like it would be a lot easier to implement.
I've also heard of mixing both technologies, so that things like the register uses a muxed sub-bus, and then that sub-bus is connected to the system bus through a tri-state buffer.
That sounds like it would complicate the addressing though.

Can someone give me a rundown on the advantages and disadvantages of mux based bus design vs a tri-state bus design?

[Anonymous No.1374676]

>>1374509
it's a freedom thermometer. probably only dissipating a few tenths of a watt

>>1374514
a mux bus would not be as easily expandable and would require lots of extra "duplicate" wire to get signals to the data selectors, but might be slightly faster and can be designed with multiple muxes supplying different inputs or units. tri-state buses need to respect the limitations of fan-in and fan-out, which may necessitate some buffering (and control for that buffering) along the bus path, but are fairly easy to wire and requires fewer packages than a data selector solution would
what are you using for your registers? if they have built-in tri-state outputs and you only need to enable them onto one internal data bus, you might use a 74xx138 decoder to drive the ~OE inputs and another to drive CLKs. the enable line to the ~OE 74xx138 is then the output enable to the internal data bus. best advice is to read a TTL catalog and see what sorts of blocks you have available. or, just use the damn FPGA

[Anonymous No.1374710]

>>1374514
Tri state is easier, going to use CPU only as bus master?

[Anonymous No.1374730]

>>1374676
I'm going to use 74hc175 for the registers.
I realize that the 74hc173 has a built in tri-state buffer, but I want my blinkenlights.
So instead I'll use the 74hc175 dff and a 74hc245 bus transceiver.

Thanks for the info, its pretty much what I've gathered.
Tri-state: easier to implement, more expandable, not quite as fast
Mux: more chips needed to implement, harder to change/expand, but a little faster.

>>1374710
Yeah, the CPU will be controlling the bus.
My plan is to use 1 byte for the bus control, so the high nybble controls the data source, and the low nybble controls the destination.
So that limits me to 16 sources and 16 destinations on the bus, but I don't expect to hit that limit.
So far I have 6 storage registers, an accumulator, instruction pointer (2 bytes), stack pointer, status register, and the memory, so that's only 12 of my maximum of 16.

[Anonymous No.1374749]

>>1374730
no ALU?
are you actually going to use the clear inputs or the complement outputs?
not that you should realistically expect more than a million or two clock cycles per second out of an HCMOS design

[Anonymous No.1374752]

Is Verilog or VHDL better for a beginner?

[Anonymous No.1374759]

>>1374752
Verilog, probably. unless you've programmed in Ada or COBOL before, in which case VHDL might feel more familiar
the best way to decide is to look at source codes and see which one feels best to you. functionally, they're equivalent

[Anonymous No.1374763]

>>1374749
>no ALU?
The ALU is tied to the accumulator.


Clear inputs.
Negative numbers will be stored in two's compliment.

>not that you should realistically expect more than a million or two clock cycles per second out of an HCMOS design
True. Guessing based on other designs, I'll probably get about 8mhz.
I would like to use a faster logic family, like the 74Gxx series or ECL, but they're so much more expensive.

[Anonymous No.1374764]

>>1374763
Oh jeez, I really butchered the formatting on that.

[Anonymous No.1374770]

>>1374763
>tied into the accumulator
so loads follow the same data path as arithmetic and logic ops, you just change the ALU op to a pass-through? hmm, beware critical paths
also, where's the address bus or register offsets?
>8MHz
we'll see. capacitance is a harsh mistress

[Anonymous No.1374886]

>>1374770
>so loads follow the same data path as arithmetic and logic ops, you just change the ALU op to a pass-through?
Correct.
I'll be using the 74hc181 ALU, which has an "Identity" operation.
The datasheet says the maximum propagation delay for the 74hc181 is 28ns, so I don't think it'll be too bad.
I don't really know though. I'm just going to build it and see how high it will clock.
All I know is that most other designs I've seen of similar complexity run at about 8mhz.


>also, where's the address bus or register offsets?
Don't have them.
The address bus will be driven by either the program counter or a paired set of storage registers.
Probably. I'm still working on that part.

[Anonymous No.1374911]

Jesus Christ why is my sig gen so shit? Input is +10dBm sine wave 1MHz and look at those harmonics. Does it generate sine waves by filtering square waves? Why is the spectrum so impure?

[Anonymous No.1374915]

Hey there /hard/, i've decided to compile a reading heirarchy to give newbies and learners more experience depending on their backgrounds, so far the two backgrounds i have come up with for starting form is a Programming background, and an Electronics background. I'll be reviewing the books in the reading list and placing then is a sort of "technology tree"/flow chart to map out progression of books in specific ordering.

I came here to tell you and to ask for your input in regards to this tree, let me know your idea of how to categorize these books.

[Anonymous No.1374926]

>>1374886
>74hc181 ALU
cool. those are uncommon birds but there seem to be a few available.
>28ns
hmm, you might consider using transparent latches instead of DFFs for the accumulator and maybe other regs as it may simplify timing of your control signals

>>1374911
odd harmonics come from clipping. -30dBc is 0.1% THD which isn't terrible
>implying we can answer that without seeing your shit sig gen

[Anonymous No.1374934]

>>1374926
Uh, its a 2MHz BK Precision 3011A.

I should test my Wavetek model 288 too, its a nicer signal gen so I'd expect a cleaner output.

[Anonymous No.1374937]

>>1374926
I'll look into using transparent latches, although pretty much everything I've ever designed used rising edge DFFs, so that's what I'm used to.
Granted I've never made anything as complex as this before.

[Anonymous No.1374954]

>>1374934
I remember people testing out baomeme radios for spurs. the 3rd harmonic was pretty bad until they put a 10-20dB attenuator in line, whereby the spurs dropped several dBc

[Anonymous No.1374957]

>>1374934
You're well within spec, it's rated for <1% distortion sine to 20kHz, <2% above.

[Anonymous No.1375692]

TTL CPU anon again, back with two more questions.

Do you guys think it would be too ambitious to have two buses, rather than just a single system bus?
Currently I'm designing around everything being on a single bus. Memory, IO, ROM, etc, but I've been thinking about allowing devices on the system bus to have DMA (namely the graphics card), but that would force the CPU to halt since I don't have any form of caching.
I was thinking that instead I could have two buses. A system/RAM bus, and a IO/expansion bus.
In that case the CPU would master it's system bus, while the IO/expansion bus would have it's own bus master, leaving all of the expansion cards free to move memory around while CPU does its own thing on the system bus.

Also: how do you create memory mapped IO?
All of the explanations I can find are actually for how to use MMIO, not how it's implemented.
Do you just have an address decoder that redirects writes from the RAM to a register when it detects specific addresses?
Surely there's a less complicated solution, because that sounds like it would get really messy really fast as you add more MMIO registers.

I hope I'm not boring everyone with all these questions.

[Anonymous No.1375706]

>>1375692
If you think you can handle it then you can try 2 busses.
You're not boring anyone, i myself find this interesting even though i only have an intro-books worth of knowledge.

I'm curious: is the system asynchronous or synchronous?

[Anonymous No.1375735]

>>1375692
>gee bill, two buses?
two buses seems like a lot of effort that doesn't buy you much. it seems like the CPU would still be required to move data between buses. a single bus with an arbiter might be simpler
>devices on the system bus to have DMA (namely the graphics card), but that would force the CPU to halt since I don't have any form of caching.
the '80s systems were fine with just stopping the processor while a DMA operation was in progress. for integrated video, they often divided bus access so that the CPU got access to RAM during "even" cycles and the video device got access during "odd" cycles (while the CPU was busy shuffling data around within itself), which does imply a bus running at double the speed of the CPU, not an unreasonable implication tbf. you'll know more once you've nailed down the timing of CPU/video bus accesses, chosen RAMs, etc. sketch some timing diagrams
>memory mapped I/O
you literally just choose a chunk of address space and send the chip selects to peripherals instead of memories. MMIO is the norm for peripherals. the 808x's "IO space" was a hack to simplify I/O devices from needing to handle the full speed of a multiplexed address bus
>really messy really fast as you add more MMIO registers.
to mitigate the mess, you would typically divide the peripheral memory space hierarchically, with (say) addr[8:6] selecting the device and addr[5:0] selecting the register on the device, with any unused upper-order bits ignored. e.g. a device with one register would simply use the decoded device-select to enable its register. multiple instances of a device could be selected by bits [5:x] with bits [x-1:0] selecting the register on the device. this could be realized as a cascade of 74xx138s whose outputs feed the next less-significant decoder's enable inputs
in practice, a lot of the peripheral mess is hidden inside ICs and a lot of the decoding mess is hidden inside programmable logic devices, yea, even unto the late 1970s

[Anonymous No.1375770]

>>1375692
I can only speak for the AXI bus but with that, you have interconnects where everything is routed through and they are aware of the address range each slave occupies so it knows where to route transactions.
Doing anything like you're planning in discrete hardware (which as I understand is your plan?) will get super painful and messy real fast. HDLs are your friend in this case, even if you just use them to "synthesize" an unoptimized circuit consisting of gate primitives.

But really, you should do this on an FPGA.

[Anonymous No.1375806]

>>1375706
My only formal education (so far) is a single "Intro to Digital Logic" course.
I'll be taking more advanced courses next semester.

>is the system asynchronous or synchronous?
It'll be synchronous. Anything that doesn't run at the bus's speed will have to be handled by the card it's housed on.

>>1375735
>two buses seems like a lot of effort that doesn't buy you much.
That's kind of what I'm worried about.
On one hand, it doubles the amount of memory that can be handled just using 16-bit addresses and it allows things to perform DMA to other things on the IO bus without interrupting the CPU, but on the other hand it complicates the addressing a bit.

>CPU got access to RAM during "even" cycles and the video device got access during "odd" cycles (while the CPU was busy shuffling data around within itself)
One problem with that is that I also have the registers on the same data bus. Wouldn't that cause issues?


Basically, the address map I currently have set out is this (top to bottom, 0x000 to 0xFFFF):
>32k: internal RAM + BASIC ROM
>24k: Video Framebuffer
>2k: Expansion Card slot 1
>2k: Expansion Card slot 2
>2k: Expansion Card slot 3
>2k: Expansion Card slot 4
And if a cartridge is inserted, then it takes the place of the internal RAM/BASIC.

What I was thinking is currently the CPU has to do all of the blit operations for the framebuffer.
But, what if I made a blitter that plugs into an expansion card slot so that it can handle the framebuffer for the CPU?
Then I realized that since DMA is going to halt the CPU, there's not much advantage to having the blitter.

That's why I though an IO bus could be handy, since it would leave the CPU free to continue working while the blitter works on the IO bus.

I don't know though. The design is a bit half baked at the moment.

[Anonymous No.1375917]

>>1375806
>doubles the amount of memory
ehhh, just cook up a bank switching or segmentation scheme, and let the really time-critical things like video have their own RAM and a bus bridge. you'll be glad you did
>One problem with that is that I also have the registers on the same data bus. Wouldn't that cause issues?
what, the CPU data regs? that's unusual. it's customary to separate the external data bus from the internal data bus with a bidirectional buffer or latch. I'm going to have to invoke rule 32 here and demand a high-level diagram
>since DMA is going to halt the CPU, there's not much advantage to having the blitter.
let's math that out.
in the red corner we have a CPU that has two 16-bit address registers with built-in increment, a third 8-bit register with decrement for counting, an 8-bit ALU, and (unusually) a memory-to-memory move instruction
in the blue corner we have a bus-master blitter that just copies flat memory blocks from one place to another without modification
initialization is presumed done
red corner copies a byte:
>fetch MOV m,m: gate PC to addr bus, gate XDB insn thru IDB into instruction reg, pulse increment of PC
>execute load-half of MOV m,m: gate SIDX reg to addr bus, gate XDB byte thru IDB into working register
>execute store-half of MOV m,m: gate DIDX reg to addr bus, gate working register thru IDB onto XDB for write
>fetch INCW SIDX: (as above)
>execute INCW SIDX: pulse increment of SIDX
>fetch INCW DIDX: (as above)
>execute INCW DIDX: (as above)
>fetch DJNC r,rel: (as above)
>execute decrement of DJNC: pulse decrement of count, gate carry out to carry flag
>fetch relative address: (as insn fetch), gate XDB thru IDB to PC, gate C flag inverted to reljump enable of PC
>fetch insn: either MOV m,m or insn after loop depending on C flag
11 cycles, assuming a non-pipelined processor. you might squeeze a couple more cycles here or there
(cont'd)

[Anonymous No.1375938]

>>1375806
>>1375735
...if you can stack fetches and executes, but that might be a complication you don't want yet
anyway, back to the contest. blue corner copies a byte:
>fetch source data: if count == done then set done flag and stop, else latch SIDX onto addr bus, gate XDB into register, pulse increment SIDX
>store destination data: latch DIDX onto addr bus, gate register onto XDB for write, pulse increment DIDX, pulse decrement count
4.5x speedup is nothing to scoff at. no instruction fetches, no execute pauses, just pure parallellism and DMA until done. if you wanted to add something like a mask generator or alpha blender to your blitter, maybe it would be a cycle slower per byte (but still worse if programmed). even rectangle support wouldn't entail much more than a handful of registers
if you don't want the CPU to completely stop, and you haven't enough bus bandwidth to run multiple cycles in the space of one CPU cycle, just have the blitter take over the bus every second or third bus cycle and implement some sort of bus handshake in your CPU (which you might well need anyway), or, if you prefer the blitter be subordinate to the CPU, have the CPU output a signal that it won't be needing the bus next cycle so that the blitter or other bus masters can prepare to do their next thing
all that said, it wouldn't hurt at all to have the video system's data/addr bus be private to the video system, and to place the blitter there. you could even have the blitter take over the private video bus whenever video memory scanning is off and pump data from the system bus to the video bus at 1 cycle per byte (caution, this can be tricky, see "clock domain crossing")

[Anonymous No.1376164]

>>>/g/65700282
>>>/g/65701749

[Anonymous No.1376165]

>>1366730
>>1369466
Then what we bring home server general here too cause usually it's a diy setup ?
Tbh, I understand why you guys moved here. the lack of mods and the fact most /v/ and /reddit/ migrated to our board ruined it badly. I'm probably a bit naive, but maybe continuing to have quality threads on /g/ and trying to show people they really don't belong in the board is the thing to do. Right now we're just leaving the ship in case it's gonna sink.

desu I'm quite gald I can still see quality post in /dpt/ and /sqt/ despite the shitposting around.

[Anonymous No.1376188]

>>1376165
>desu I'm quite gald I can still see quality post in /dpt/ and /sqt/ despite the shitposting around
i am too anon,
i am too...

I wish there were less shit, but i 1) have a busy schedule and 2) don't want to deal with the cancer, so for the moment /hard/ will be on /diy/, in the future i may try a double-thread once i figure out how to make a thread-bot to keep the general running.

/diy/ seems to have more of an interest in hardware then /g/ does honestly, and /g/-fags are too busy shilling le amd ecks dee and le intell ecks dee dee

[Anonymous No.1376189]

>>1375692
>Do you guys think it would be too ambitious to have two buses, rather than just a single system bus?
If the other bus is dedicated for program memory, then it most likely simplifies your design.
I think I've seen only one processor with two separate general purpose buses (and a third bus for program fetch).

[Anonymous No.1376243]

what's some cool stuff you would do with the following hardware?
- a bunch of intel pc sticks (STCK1A32WFC)
- a bunch of intel NUCs (NUC5CPYH)
- a bunch of orange pi zeros
- a bunch of these: https://wiki.hackerspace.pl/projects:zsun-wifi-card-reader
what interesting stuff have you seen done with small machines?
I plan on making some fun (and potentially commercial) projects with mini-pcs and wifi.

[Anonymous No.1376286]

>>1376243
>>1376243
I'd probably just create a self-running self-harvesting greenhouse in my basement with some RPi's.
I would power it with a self-maintaining nuclear thermogenerator (a lump of hot uranium/plutonium/thorium that generates a voltage potential across a series of transistors and diodes).

I would also build a mini super-computer to so some deep-learning and super-computing, then i would brag about it on /g/.
I'm not very creative :(

[Anonymous No.1376777]

>>1366530
it is here

[Anonymous No.1377004]

>>1376777 (nice trips, kek is with us)
What does it do/will it do senpai desu?

[Anonymous No.1377048]

>>1377004
The top 2 pcb's are the front and back of a 180 volt boost converter which will supply power to my nixie tubes

[Anonymous No.1377052]

>>1376777
aesthetic, but minimum copper removal wasn't the best design rule for a HV circuit, nor is 2.54mm much separation for 180Vdc terminals. anyway, good luck. what's U1?

[Anonymous No.1377190]

I'm building a small electronic device in an enclosure made of wood and aluminum that needs a micro usb female port.
What could I use to make my device look good? I only found variants of pic related on google/ali.

[Anonymous No.1377269]

>>1377048
rad

[Anonymous No.1377540]

>>1377190
Pan-head screws.

[Anonymous No.1377567]

I found a nice Dell Monitor in a dumpster. Took it home, plugged it in and it doesn't power on, completely dead. I've dismantled it and one of the pins on the transformer on the PSU has shorted with the metal casing surrounding the LCD. The transformer doesn't appear damaged, the windings and pins aren't burnt and still good.

Am I right in assuming that the short has most likely killed the LCD or display controller and it's not worth trying to repair? I was thinking of getting a replacement transformer although searching the codes on it doesn't return much so any help there would be appreciated. If it's cheap I think it'll be worth trying at least.

[Anonymous No.1377577]

>>1377190
like the bulkhead cable on the left, cheapo board-mounted micro USB connectors are usually designed to be set back 1.5-3mm from the outside case surface. just get a nice cover plate laser-cut and you could either use the bulkhead cable or mount the board on which the connector lives in the case so as to fit that setback

[Anonymous No.1377639]

>>1377567
Desolder the transformer to see if it's open-circuit, might be just a thermal fuse if it is. But first check any other fuses, diodes, or FETs that feed/drain from that trace. A short to ground likely won't have killed any of the electronics (assuming it uses isolated flyback converters) since it shouldn't cause a voltage spike.

[Anonymous No.1377750]

>>1369063
goatse

[Anonymous No.1378018]

>>1377639
Thanks, I'll give that a try.

[Finding old game No.1378214]

>>1366940
How does he get out without breaking all the components?

[Anonymous No.1378225]

I am trying to program an stm32 board using the following tutorial http://grauonline.de/wordpress/?page_id=1004 the only problem I have is that I don't have a Serial-to-USB converter so I am using an arduino uno with the reset pin tied to ground and the tx and rx pins connected over 2 voltage deviders (2.2k and 3.3k ohm) to get 3V tx and rx signals. But when I try to upload I get:
Failed to init device.
stm32flash Arduino_STM32_0.9

[Anonymous No.1378228]

>>1378225
my scope doesn't see anything happening on the rx pin

[Anonymous No.1378381]

>>1378225
I'd recommend you to just get a serial-to-usb or a stlink, both are just a couble bucks and are useful af

[Anonymous No.1378391]

>>1378381
They are really cheap and I did order one but aliexpress shipping takes a long time

[Anonymous No.1378788]

I know this is a bit /g/, but has anyone here written their own calculator code to put on a microcontroller or rasPi so they could get features that common calculators (or apps) don't have? Thinking I want one with conversions to natural units that stores dimensions for each number (length, time, temperature, etc.) Also one that I can plug different (7-seg, OLED, bar graph) displays into. Just wondering what I'm in for if I do decide to make one.

[Anonymous No.1379636]

>>1378788
you're going to be in for a microcontroller with lots of flash, and for writing a bunch of display drivers (and maybe a keyboard driver or three), and maybe designing an application-specific windowing-type system
other than that, once you have it working on the desktop, it shouldn't be particularly difficult to port into an embedded environment. I always thought it could be fun to put the units utility into a portable calculator

[Anonymous No.1379701]

>>1379636
Well truth be told I use a desktop calculator with about every feature except units, and it allows me to copy-paste values from the calculator to spreadsheets and such on my computer, but I'm thinking having a of calculations would be something I could write to storage within the unit calculator and later (or perhaps simultaneously) extract this onto my computer. Though in reality I just want to design a project for nixie tubes.

[Anonymous No.1379782]

Sorry for ghosting. Finals week and all that.

>>1375917
>it's customary to separate the external data bus from the internal data bus with a bidirectional buffer or latch.
Derp, I totally didn't do that.

>it wouldn't hurt at all to have the video system's data/addr bus be private to the video system
Yeah, that's what I wanted to do initially.
Basically everything the CPU wanted to do to VRAM would have to go through the blitter.
But I'm planning on putting the blitter off until later, because I don't really have any good ideas for how to implement it at the moment.

Thanks for all the info.

>>1376189
I don't really want to go with a Harvard architecture.
While it does simplify things somewhat, there's a lot of drawbacks as well.
Namely that I would like the ability to have things like self modifying code.

Also, I give in. I'll be implementing this on an FPGA, if only because I realized how rare some through hole 74xx chips have become.
So, what's a good FPGA board to get?
I kind of like the iCE40 series because they have an completely open source toolchain, but that also limits me to 8k LUTs, and the breakout board is pretty barebones.
How's the Papilio Pro?

[Anonymous No.1379805]

>>1379782
you can still have video on a private bus. you just need to have some sort of bridge between the two. previously it was the blitter. now it can just be a dirt-simple bridge with a wait state generator that waits until your video hardware isn't accessing the bus, or even more simply, for border/blanking time
>FPGA
you won't regret this, I promise
imho get the barebones board (with RAM) and connect your own lights/switches. you pay a lot more for a 7-segment LED display and a few pushbuttons on the board than off, where you can use/reuse them in assembled projects. don't forget to buy "Dupont" leads, lots of 'em
>papilio pro
the trouble with Xilinx is that the programming flow without their proprietary JTAG pod isn't perfectly smooth. you can buy clones of their USB platform cable for $25 or so which helps. the $5 Altera USB Blaster clones are well supported by the official Altera software
you should definitely shop around for boards. there are a lot of Cyclone IV options on alibay, for example https://www.aliexpress.com/item/i-am-not-a-potato/793367437.html has tons of room, enough that you could reasonably build a simple 32-bit design in it or (by 16-bit standards) one hell of a video system

[Anonymous No.1379818]

>>1379805
I've actually used the Altera DE1 in my Digital Logic course, so I'm somewhat familiar with them.
Does the free version of Quartus have any big limitations?

I might go for the iCE40HX8k dev board or one of the Cyclone boards. I really don't have a good feel for how many LUTs something like this will take.
I mean, the MOS6502 has 3,510 transistors, which is like 1700 gates. Since every LUT has 4 inputs that means that it would take less than even less than 1700 LUTs to implement it.
That just sounds really small to me.

Honestly iCE40s are so cheap I might go for those and just use multiple chips.
Like one for the CPU, another for the VGA adapter.

[Anonymous No.1379823]

>>1379818
>Quartus Prime
no support for higher-end devices, the usual ModelSim Starter limitations, maybe some IP cores aren't available... that's all I can remember
>1700 gates
there was also a control/sequencing ROM on the chip. in FPGA, you'd probably just partially/fully microcode it. then there's not much left but a tiny counter, registers, routing, and a couple of adders

[Anonymous No.1379828]

>>1379823
Well, I probably won't be using the top of the line chips, so I guess that won't be an issue.
>the usual ModelSim Starter limitations
Like what? I've only used the full version my college provides.
>IP cores
Definitely won't be using those, since I'll be implementing everything myself.


Oh, and I guess one more question:
Can FPGAs do tri-state logic? Both internally and on the IO pins?
Since I've opted for a tri-state bus design I kinda need that.

[Anonymous No.1379833]

>>1379828
ModelSim Starter is artificially throttled down after I forget how many lines of code. not a big deal, you can simulate with external tools
>IP cores
it might not be a terrible idea to make use of SDRAM controllers if provided
>tri-state logic internally
not really. you would need multiplexers to select a source for the bus you'd be driving
>on the IO pins
absolutely, Pic related

[Anonymous No.1379837]

>>1379833
Thanks!

[Anonymous No.1379842]

G

[Anonymous No.1380332]

A

[Anonymous No.1380453]

N

[Anonymous No.1380462]

Hey
I need a new soldering iron. The last one I had was a hand-me-down from a university. I'm looking for one right now, but the vast majority of them are extremely cheap, now. Either not getting hot enough or being unsafe to use because they, themselves, aren't wired very well.

So, what is your suggestions for someone who just does regular desoldering/soldering on things like audio cables and the occasional PCB? I typically use it in conjunction with protoboards.

[Anonymous No.1380464]

>>1380462
Also, how are the two-in-one stations that have an air gun on one side and an iron on the other? One of those could be useful.

[Anonymous No.1380654]

>>1380462
>>1380464
If you're just doing through hole stuff and wires, then a fixed 25w soldering iron should work just fine.
I used the iron that came with my "Learn to Solder" kit for years.

But if you want to do anything SMD, then the hot air guns are really handy.
The other thing the hot air gun is good for is de-soldering DIP package components.

[Anonymous No.1380730]

>>1380654
>a fixed 25w soldering iron
TEMPERATURE CONTROLLED OR NOTHING

[Anonymous No.1380871]

>>1380462
here are some cheap things I bought:
>>/diy/thread/1363100#p1368748
though I can't recommend them yet, some still haven't arrived, some I haven't used yet.
the QUICKO iron and the 8858 hot air gun have good reviews, though.

[Anonymous No.1380904]

>>1380464
>two-in-one
love my Aoyue 888A. hot air stations can be useful even in removing THT parts. would buy again

[Anonymous No.1380925]

>>1361852
anime but mainly manga pictures are what's good, not trap shit and what not, only shit that's from actual anime and what not as in like professional shit. gays and liberals caused traps, along with deviantart

[Anonymous No.1381131]

>>1365303
arduino, which is powered by 9v battery
doesnt arduino run on 5V?

[Anonymous No.1381133]

>>1361784
>using schematic instead of board layout to place components
absolute madgirls

[Big Tony !!AB4f2ULK+UF No.1381161]

>>1381131
>arduino, which is powered by 9v battery
>doesnt arduino run on 5V?

yes but the main power jack leads to a 5 volt regulator and typically says 9-12 volts but the actual range is larger.

why comment on arduinos when you are not a tarduino?

[Anonymous No.1381254]

>>1381161
>dropping 4V on a linear reg
ew

[Anonymous No.1381268]

>>1381133
that is a board layout, my dude
>carrying huge chunks of ceramic without back support
now that's absolutely madgirl

[Anonymous No.1381282]

>>1381254
There's a reason most Arduino projects are powered by USB.
9v is pretty much the most you can put into them without the reg overheating.

[Anonymous No.1381381]

>>1381268
Im talking about the paper

[Anonymous No.1381409]

Is it possible to learn hardware description only with simulations?

I know electronics but I've always been on the microcontroller side.

[Anonymous No.1381485]

>>1381409
absolutely, but it's useful to have a good synthesis tool that will locate things like critical paths and asynchronous constructs in your design. some FPGA tools will even create an HDL output of your synthesized design, annotated with actual gate/pin delays

[Anonymous No.1382046]

I want more time with a VNA, but they all seem to be $5k+. Is there nothing <$1k?
>>1381409
Yeah, check out Quaruts Prime/ModelSim, it's free.

[Anonymous No.1383523]

More FPGA questions:

Should I learn Verilog or VHDL? (Or Spinal HDL?)
I haven't really learned either. In my digital Logic class we used Quartus' block diagram format.

[Anonymous No.1383611]

>>1382046
Yeah its called a second hand signal generator and scope. Learn maths

[Anonymous No.1383699]

>>1383523
they're basically the same. Pascal-insipred Verilog has slightly better free tooling and imho looks a lot saner than COBOL-inspired VHDL, you may feel otherwise

[Anonymous No.1383724]

>>1383699
Yeah, I've only done a little bit of each, and to be honest, I don't care much for either.

I greatly preferred the block diagram format, but I realize that using block diagrams aren't the best for large projects like a CPU, and are FAR less portable than HDL.

I guess I'll go for verilog.

[Anonymous No.1383728]

>>1383724
also, fwiw, it seems that verilog has a lot more free/open code floating around that you can look to for learning

[Anonymous No.1383765]

>>1383728
That's good to know!
Most of what I've been looking at so far has been VHDL from Papilio, but that's just been so I can get an idea of how other people implement things like a VGA controller.

Honestly, Papilio has been a pretty great resource so far, I just wish they didn't hide the source code under mountains of .bit files and horrid organization.

[Anonymous No.1383775]

>>1383765
https://www.librecores.org/project/list
has some good stuff, but not many examples of the same function. github search for language:verilog does turn up some nice basic stuff including a Verilog tutorial of some sort on the first page

[Anonymous No.1383823]

>>1383775
Nice!
Also, any good resources on bus bridges?
I can't find any good into on them.
The best I've been able to come up with is a device that sits on the main bus and has two registers: address and data.
I mean, it would work, but that's pretty grossly inefficient since the CPU would need to perform three writes to do anything on the bridged bus.

Just banking the busses seems like an easier solution

[Anonymous No.1383836]

>spend hour and a half hand cutting jumper wires for group of 7-segment displays
>testing pinout with jumper cable
>forget to put resistor in series with cable
>fry second (2nd) 7 segment display of the week
just FUCK me up

[Anonymous No.1383846]

>>1383823
>banking
that's the usual way to do it: pass through some number of address and control lines (possibly decoded from or augmented by other address and control signals), and coordinate a bidirectional buffer/latch on the data lines, and that's about all there is to it. it's best looked at from the bus-cycle level. if the control signals are the same on both sides you basically just need that buffer/latch, its controlling circuitry, and possibly a bus arbiter, to decide which master should get access in the case of multiple master requests
consider how your system will handle bus wait states. there are many models for this, from the simple nHOLD line on 808x, to the slightly more complex handshaking available on the 68000, to the complex but parametrizable Wishbone bus. it's probably easiest to use whatever signals/protocols your peripherals and other devices are using

>>1383836
bruh

[Anonymous No.1383855]

>>1383836
RIP. How may did you buy?

[Anonymous No.1383862]

>>1383846
I'll probably go with something like the HOLD line.
I'm not experienced enough yet to implement anything that much more complex.

[Anonymous No.1383872]

>>1383855
I just bought more off of amazon. These came from a beginner electronics kit I bought like 4 years ago when radio shack went bust and only now got to using.
In total I had 5, now it's down to 3.

[Anonymous No.1383873]

>>1383862
luckily for you, it all boils down to a HOLD signal: does the processor go on to the next step, or not? anything more complex can be built atop the HOLD signal
it's worth reading about the Wishbone bus, since it's not actually that complex, much of it is optional, there's lots of IP designed for it, and it's synchronous and therefore well-suited for HDL synthesis. see http://indico.ictp.it/event/a11204/session/35/contribution/22/material/0/0.pdf, especially slides 23 and 24 for an instructive example of a simple general purpose output port, with VHDL source

[Anonymous No.1383876]

>>1383873
Cool, I'll give that a look.
I've seen wishbone pop up a lot in my searches, but all of the descriptions left it looking kinda complex.
I also saw it has a derivative, the "Simple Bus Architecture".

[Anonymous No.1383884]

>>1383876
oh neat, I did not know about SBA. the only thing missing in that subset is bus handshaking, which you would probably mostly only need if you were accessing things outside the SoC. if the FPGA you chose has internal RAM, you wouldn't necessarily even need to worry about handshaking. even if you were to use external memory, you can usually get away with a fixed number of wait states as long as the external device is asynchronous (for something like a synchronous external bus, you'd generate ACK from the bus interface state machine)
Pic related: pseudo-verilog that adds 4 wait states to the simple example

[Anonymous No.1383887]

>>1383884
Yeah, I've been thinking about internal RAM.
The Papilio Pro has 64kbytes of RAM, and the ice40hx8k has 16kbytes.

The problem is that my VGA adapter uses ~74kbytes, which means it fits in neither.
I could drop the hardware layering, which brings the memory footprint down to ~48kbyte, but I really like the advantages the hardware layering brings to the table.
Either way, it won't fit on an ice40.
I also want the full computer system to be able to use carts.

That really just leaves me with being able to use the onboard RAM as just plain old system RAM for the full computer.
There's no way I'll be able to fit the whole thing in a single FPGA with the VGA sucking up so much memory.

[Anonymous No.1383901]

>>1383887
then external RAM is the way you would probably want to go, and the SBA won't be enough. otoh, if you understand the SBA, you would only need to add the handshaking signals from slide 19 and simply not advance your CPU's state while the CPU's STB_O is low and ACK_I isn't. just understand that interlock on top of SBA and you'll be able to use a lot of neat things
this is the part of the process where you'll want to start drawing out timing diagrams for your buses and peripherals, if you haven't already
note that if you use internal RAM to buffer whole lines of your framebuffers ahead of time, your VGA hardware can get to that data exactly when it needs it
there are more than a few SDRAM controller designs kicking around out there, including some with multiple slave ports, which would make it easier to share RAM between the CPU and the video system

[Anonymous No.1383907]

>>1383901
I'll look into that.

So far I don't really need any handshakes though.
All of the hardware I've designed to go on the bus is either simple RAM/ROM, or a memory mapped IO device w/ interrupts.

I probably will need to implement a handshake though because latter on when I start making more complex add-ons like blitters the whole situation becomes more complex.

[Anonymous No.1384234]

Hey there try/hard/s
I'm looking to make my own crypto miner, what do i need and where do i go? I'm new to hardware but have some programming experience (python)

[Anonymous No.1384361]

>>1384234
as in, your own ASIC?

[Anonymous No.1384413]

Is this doable?

I'm building a robot and I'm going to be using an RTOS but at the same time I want to read two rotary encoders (two external interrupts)

pseudocode:

enable external interrupt 1
enable external interrupt 2

rtos start
rtos subroutine 1
rtos subroutine 2
... rtos subroutine n


I'm using PIC18 series microcontroller if it matters

[Anonymous No.1384419]

>>1384413
>not using an STM32 whose timers have built-in rotary encoder counting support
I don't see why it wouldn't be "doable", it's just a matter of keeping your ISR's short and sweet

[Anonymous No.1384995]

Is there a peripheral that lets me connect several CPU's to a single board? I'm thinking of trying something.

[Anonymous No.1384997]

>>1384995
let me elaborate:
I plan on using some kind of maguffin (what i'm asking you for) to connect several CPU's to a single "coordinator" microprocessor, which in turn is connected to a central board that orchestrates the entire system.

[Anonymous No.1385005]

>>1384997
there are a shit-ton of them
parallel processing is a whole field of study unto itself. figure out what you actually want to do then come back
in the meantime, maybe start with ethernet

[Anonymous No.1385006]

>>1367321
Thanks, would you happen to have a link for the first one, the electricity one? having a hard time finding it.

[Anonymous No.1385007]

>>1378214
Maybe he has one of these?

[Anonymous No.1385009]

>>1385005
No i mean CPU's require a socket which needs to be built into a motherboard, i'm hoping to find some kind of seperate self-contained CPU socket which has an ethernet port to transfer data, then i hope to connect 2 or more to microcontrollers that recieve data dn distribute it between the CPU's in a pipeline like fashion. Its not hard but i need to know the name of such a device.
I need a self-contained CPU socket peripheral which can be connected to a computerized system. I have a idea of my entire system but i just want to know if suach a preipheral exists and where i can buy it?

[Anonymous No.1385013]

>>1385009
there is none. you learn logic design and you design one yourself from scratch.
>it's not hard
yep, you're shitposting, no help for (You)

[Anonymous No.1385016]

>>1385009
>i just want to know if suach a preipheral exists and where i can buy it?
It does not. What you're looking for is a regular computer mobo + cpu + ram connected to other computers (be it through Ethernet or infiniband).

[Anonymous No.1385025]

>>1385016
oh, ok
>>1385013
b-but i'm not senpai

[Anonymous No.1385051]

>>1384413
encoders should not be handled by interrupts, ever

[Anonymous No.1385053]

>>1385051
that's a bold claim. can you elaborate on that?

[Anonymous No.1385078]

>>1384419
After struggling with the ancient Pic18 series I decided for this, even if I lost a lot of work seems the most sensible thing.

[Anonymous No.1385240]

>>1381282
>9v is pretty much the most you can put into them without the reg overheating
They have absolutely no problem running on 12V, 18+ is when they start to have overheating.

[Anonymous No.1385261]

>>1385240
Depends on what kind of work you've got your ardy running. Just a few 10k pull-ups then no problem, but trying to source a hundred mA or two for a relay or low-hFE BJT then you probably could overload the regulator.

Anyone ever tried to make a capacitive converter whereby you move the plates closer and further apart so the same charge on it produces a different voltage?

[Anonymous No.1385291]

>>1385053
Not him, but it isn't that unusual for the encoder to stop just between 0 and 1, in which case any slight noise can produce shitloads of interrupts, crippling the rest of the software.
Also, depending on the encoder, simply turning it fast enough can produce more interrupts than your sw can handle.

[Anonymous No.1385319]

>>1385291
hmm, stupidly, I hadn't considered an encoder without detents, good point

[Anonymous No.1385890]

So some rando gave me a board recently.
How the fuck do i power this thing? What is it? Where do i find documentation for it?

[Anonymous No.1385899]

>>1385890
looks like a PC motherboard to me. attach monitor, USB keyboard and ATX power, and fire it up. it should then tell you what it is
further correspondence to >>>/g/

[Anonymous No.1387268]

>>1385006
https://mega.nz/#!GfYAjaSY!dzQ4p_QgOMUR--a3EXjEGC-B21X0OKECD-C1E9GWIak

[Anonymous No.1388266]

How the FUCK do I fix this
Idk whats even doing.

What is the burnt 5 leg component?

[Anonymous No.1388268]

>>1388266
>>1388266
It's close to the USB power port

[Anonymous No.1388278]

>>1388266
I lifted lid #2.
Is the cunt fucked?

[Anonymous No.1388368]

>>1388278
I'd say so, how'd ya blow it?

[Anonymous No.1388399]

>>1388368
I don't know, it was an employee assigned device. A very talented employee that loves to snack on crayons.

I'm guessing they somehow put too much voltage into the charge port but I have no idea.

[Anonymous No.1388410]

>>1388399
What is it?

[Anonymous No.1388438]

>>1388278
that lithium charge controller is fucked

[Anonymous No.1388449]

>>1388410
Tablet, kind of expensive one

[Anonymous No.1388567]

>>1388438
Wow, it's got lots of pins for power management. I guess it monitors power used by all the main parts of the board.

>>1388449
Blew when charging I suppose. Want to check the inside of the charger itself? It says -0.3V-11V on it, a power spike making it through from mains may have done the deed. If your chargers don't have MOVs or gas-discharge tubes in them that may be the problem. Having class-X suppression caps should also help. If you've got cheap chargers then replace them. If the charger or tablet have "fast charging" that may be suspect, also if the tablet was pulling more current than the charger would let it.

But if that lead turns up nothing there's nothing to say that the issue wasn't caused by a problem in the tablet itself, whether one that made it through QC or one brought on by insufficient cooling or ingress.

[Anonymous No.1388660]

>>1388567
I didn't have him return the charger, just issued a new tablet.
He either had the original charger, or some anker dual port 2.4a thing. Although he could have used a personal charger.
I can't spot any possibility of water damage, so I really don't know how.
It's a long shot but maybe they charged it with a sketchy vehicle charger while using a line in port and it somehow had a voltage difference between the USB port and the aux port ground. That is assuming that it's tied together as a common ground.

I've had nearly 70v between a charging surface pro, and my magnesium bodied laptop that was also charging. But I doubt it's any amps. Maybe something like that

[Anonymous No.1388965]

>>1388660
>'ve had nearly 70v between a charging surface pro, and my magnesium bodied laptop that was also charging.
I know what you mean, but that will have been with power supplies that run off mains. Usually such flyback converters are isolated, but often they have noise suppression capacitors across the windings, which will pass a very small current through but enough to reach a significant voltage. Oddly enough more expensive chargers do this worse, because they incorporate more noise suppression.

But in a car is a different story, because the audio will be probably based off a 6V ground. If the car-charger wasn't an isolated one (it certainly doesn't have to be for a simple DC-DC converter) then it's easily possible for a big current to flow. You'd need a balun/isolation transformer for the aux or an isolated DC-DC converter for the power supply that can handle the current.

[Anonymous No.1389193]

>>1371717
Rolling

[Anonymous No.1389542]

>>1371717
roll

[Anonymous No.1389599]

>>1371717
roll

[Anonymous No.1389673]

>>1371717

[Anonymous No.1389806]

>>1387268
Thanks

[Anonymous No.1389991]

hi guys, just got into IT and I have a question that /g/entoomans didn't answer
any guides on how to use a tester to diagnose a malfunctioning mobo or psu capacitor and fucked molex cables?

[Anonymous No.1390089]

>>1375770
>AXI
>bus
REEEEE

[Anonymous No.1390571]

While it is still readable, how come a billion dollar company can't make scaleable schematics?

[Anonymous No.1390579]

>>1385261
I thought most people use an interface board for relays?

So that the Arduino boards basically just provide a signal, with negligible current draw.

[Anonymous No.1390581]

>>1390579

[Anonymous No.1390900]

>>1390579
Well if you only need a single relay I imagine you could run one off an arduino output, though I still wouldn't do it.

[Anonymous No.1391402]

In my 8085 project, I have used a 7x6 key matrix connected to a 8155 chip. The project involves typing on a character LCD. Now sometimes, while typing, the cursor goes anywhere on the screen, it doesnt take any more input. It feels like it has entered halt state after that point, and I have to reset it. It doesnt happen everytime but its not very infrequent.

[Anonymous No.1391598]

Speaking of basic bog standard ATX pc power supply units, they always have two +12V wires, right? I'm asking because i'm considering getting the cheapest one i can find on my countrys equivalent of craigslist to power my 3d printer build which requires two +12V wires and maybe two hundred watts or less.
So basically will i be fine if i just buy pic related? and yes i know you can probably see it straight away from that spec sheet there but i'm an idiot especially when it comes to electronics so i'm not quite so sure.

[Anonymous No.1391612]

>>1391402
>In my 8085 project,

no offense, but did you lose a bet?

[Anonymous No.1391701]

>>1391598
Yeah that one has two 12 rails.
12v1 (10A, Yellow) and 12v2 (15A, Yellow/Black).
That's just enough to put the heated bed on one rail and hotend on the other.

I would check if it actually can maintain that though. Older/cheaper PSUs generally can't maintain their maximum rated output.

[Anonymous No.1391725]

>>1361784
has /g/ descended so deep into /b/-level bullshit that this topic migrated to /diy/?
(before anyone flips their shit; pic related is not to be taken literally. I, for one, welcome our refu/g/ees.)

>>1391598
Not all necessarily have two separate "rails," but it's become very commonplace to have more than one since quite a while ago. I think only super low power (or super cheap) units would have only one 12v rail.

[Anonymous No.1391794]

>>1391725
>has /g/ descended so deep into /b/-level bullshit that this topic migrated to /diy/?
Unfortunately, it has. If you look on any archives you will find that only 2 threads did well and the rest floundered and died under the endless tides of "MY RAM IS BIGGER THAN YOURS!!!" and "LOOK AT MY DRAGON DICK DESKTOP BATTLEL STATION!!!!". Certainly not as bad as /b/ but this is such an esoteric thread topic to so many /g/-tards and not as instantly-gratifying as shit posting that the thread quickly slides and dies. It was moved to /diy/ since it would fit in better and wouldn't drown like on /g/. It might do reasonably well on /tech/ since 8ch still retains some of the essence of the good old chan.

[Anonymous No.1391833]

>>1368960
after digital fundamentals, if you've mastered them, weste and harris would be next if you're wanting to learn more about design.

[Anonymous No.1391912]

>TFW you finally have a small equipment stack
Aw yeah! Time for some fun projects now.

I think I'll start with a simple cw ham radio transmitter.

[Anonymous No.1391913]

>>1391912
Oops, forgot image.

[Anonymous No.1391958]

>>1391913
Well I'd personally start with receivers as opposed to transmitters; you can refine your circuit-building techniques without shitting up the local spectrum.

Wanna give a price estimate on that hardware?

[Anonymous No.1391979]

>>1391913
Oh, I have a bit older model of that same signal generator. Gain and offset accuracy sucks and the PC software isn't exactly the greatest thing ever.

Has the newer model fixed those?

[Anonymous No.1392035]

>>1391958
I can put the transmitter in a metal can and use a bnc connector on the output.
That should contain any spurious transmissions.
Otherwise, yeah, starting with receivers isn't a bad idea, it's just that I've already made a few of those.

Prices were $70 for the hot air rework station, $380 for the oscilloscope, $380 for the function generator, and like $12 for the two substitution boxes.
So about $850 in total.

>>1391979
I haven't used the PC software, but gain and offset seem fine.
I've mostly been testing how it well works at the extremes of what it can do (sine and square waves at max freqency and max amplitude)

[Anonymous No.1392060]

>>1392035
>$12 for the two substitution boxes
That's not bad. As long as you've got some way to analyse the signal (and noise) you're producing there isn't a problem, assuming you're licensed to transmit on that band to begin with. Check out the ham radio general on /diy/ too.

[Anonymous No.1392122]

New Thread This Way:
>>1392120
>>1392120
>>1392120
>>1392120
>>1392120
>>1392120